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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

The present document is part 1 of a multi-part deliverable covering the Test specification for the Host Controller 
Interface (HCI), as identified below: 

Part 1: "Terminal features (Release 7)"; 

Part 2: "UICC features (Release 7)" ; 

Part 3: "Host Controller features (Release 7)". 



Introduction 

The present document defines test cases for the terminal relating to the Host Controller Interface (HCI) as specified in 
TS 102 622 [1]. 

The aim of the present document is to ensure interoperability between the terminal and the UICC independently of the 
respective manufacturer, card issuer or operator. 
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1 Scope 

The present document covers the minimum characteristics which are considered necessary for the terminal in order to 
provide compliance to TS 102 622 [1]. 

The present document specifies the test cases for: 

• the HQ core as described in the first part of TS 102 622 [1]; 

• the contactless platform as described in the second part of TS 102 622 [1]. 

Test cases for the UICC relating to TS 102 622 [1] and test cases for the Single Wire Protocol (SWP) covering both 
terminal and UICC are out of scope of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version 
of that document in the same Release as the present document. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox. etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 622: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Host Controller 

Interface (HCI)". 

[2] ETSI TS 102 613: "Smart Cards; UICC - Contactless Front-end (CLF) Interface; Part 1: Physical 

and data link layer characteristics". 

[3] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)". 

[4] ISO/IEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 

[5] ISO/IEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 2: Radio frequency power and signal interface". 

[6] ISO/IEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initialization and anticollision". 
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[7] ISO/IEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 4: Transmission Protocol". 

[8] ISO/IEC 7816-4: "Information technology - Identification cards - Integrated circuit(s) cards with 

contacts - Part 4: Interindustry commands for interchange". 

[9] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[10] ETSI TS 102 695-3: "Smart Cards; Test specification for the Host Controller Interface (HCI) 

Part 3: Host Controller features". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 102 622 [1] and the following apply: 

allowed error response code: response code which is not ANY_OK and which is allowed for the referenced command 
as specified in TS 102 622 [1] 

non-occurrence RQ: RQ which has been extracted from TS 102 622 [1], but which indicates a situation which should 
never occur 

NOTE: The consequence is that such RQs cannot be explicitly tested. 

user: describes any logical or physical entity which controls the test equipment in a way that it is able to trigger 
activities of the DUT 

3.2 Symbols 

For the purposes of the present document, the symbols given in TS 102 622 [1] and the following apply: 

PIPE0 the static pipe connected to the link management gate of the device under test. 

PIPE1 the static pipe connected to the administration gate of the device under test. 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 102 622 [1] and the following apply: 

DUT Device under test 

FFS For further study 

HCI Host Controller Interface 

HCUT Host controller under test 

HS Host simulator 

ICRx Initial condition requirement (where x is a number) 
NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

NAA Network Access Application 
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PCD Proximity Coupling Device 

PICC Proximity Card 

RF Radio Frequency 

RO Read-Only 

RQ Conformance requirement 

SRx Static requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

TRx Trigger requirement (where x is a number) 

NOTE: As used in the applicability table; see clauses 4.2 and 4.5.2. 

3.4 Formats 

3.4.1 Format of the table of optional features 



The columns in table 4. 1 have the following meaning. 



Column 


Meaning 


Option 


The optional feature supported or not by the DUT. 


Status 


See clause 3.4.3. 


Support 


The support columns shall be filled in by the supplier of the implementation. The following common 
notations, defined in ISO/IEC 9646-7 [9], are used for the support column in table 4.1 . 
Y or y supported by the implementation 
N or n not supported by the implementation 

N/A, n/a or - no answer required (allowed only if the status is N/A, directly or after evaluation of a 
conditional status) 


Mnemonic 


The mnemonic column contains mnemonic identifiers for each item. 



3.4.2 Format of the applicability table 

The applicability of every test in table 4.2 is formally expressed by the use of Boolean expression defined in the 
following clause. 

The columns in table 4.2 have the following meaning. 



Column 


Meaning 


Clause 


The "Clause" column identifies the clause containing the test case referenced in the "Test case number 
and description" column. 


Test case 
number and 
description 


The "Test case number and description" column gives a reference to the test case number (along with 
the corresponding description) detailed in the present document and required to validate the DUT. 


Release 


The "Release" column gives the Release applicable and onwards, for the corresponding test case. 


Execution 
requirements 


The usage of the "Execution requirements" column is described in clause 4.5.2. 


Rel-x Terminal 


For a given Release, the corresponding "Rel-x " column lists the tests required for a DUT to be declared 
compliant to this Release. 


Support 


The "Support" column is blank in the proforma, and shall be completed by the manufacturer in respect of 
each particular requirement to indicate the choices, which have been made in the implementation. 
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3.4.3 Status and Notations 

The "Rel-x" columns show the status of the entries as follows: 

The following notations, defined in ISO/IEC 9646-7 [9], are used for the status column: 
M mandatory - the capability is required to be supported. 

O optional - the capability may be supported or not. 

N/A not applicable - in the given context, it is impossible to use the capability. 

X prohibited (excluded) - there is a requirement not to use this capability in the given context. 

O.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 

identifies an unique group of related optional items and the logic of their selection which is 
defined immediately following the table. 

Ci conditional - the requirement on the capability ("M", "O", "X" or "N/A") depends on the support 

of other optional or conditional items, "i" is an integer identifying an unique conditional status 
expression which is defined immediately following the table. For nested conditional expressions, 
the syntax "IF ... THEN (IF ... THEN ... ELSE...) ELSE ..." shall be used to avoid ambiguities. 

References to items 

For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the 
conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item 
number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters 
(a, b, etc.), respectively. 

EXAMPLE: 4. 1/4 is the reference to the answer of item 4 in table 4. 1 . 

4 Test environment 

4.1 Table of optional features 

The device supplier shall state the support of possible options in table 4.1. See clause 3.4 for the format of table 4.1. 



Table 4.1 : Options 



Item 


Option 


Status 


Support 


Mnemonic 


1 


Data link layer specified in TS 102 613 [2] is used 


O 




O_102_613 



4.2 Applicability table 

Table 4.2 specifies the applicability of each test case to the device under test. See clause 3.4 for the format of table 4.2. 
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Clause 4.5.2 should be referenced for usage of the execution requirements which are referenced in table 4.2 a) and 
described in table 4.2 c). 



Table 4.2 a): Applicability of tests 



Clause 


Test case number and description 


Release 


Execution 
requirements 


Rel-7 
Terminal 


Support 


5.1.3.2 


Test case 1 : existence of gates 


Rel-7 




M 




5.1.3.3 


Test case 2: processing of RFU gate identifier 


Rel-7 




M 




5.1.4.2 


Test case 1 : static pipe deletion 


Rel-7 




M 




5.1.4.3 


Test case 2: initial pipe state and persistence of 
pipe state and registry value 


Rel-7 


TR1 


M 




5.1.5.2 


Test case 1 : registry deletion 


Rel-7 


SR1 


M 




5.2.2.2 


Test case 1 : commands/events on pipe which is 
not open 


Rel-7 




M 




5.3.1.2.3.2 


Test case 1 : ANY_OPEN_PIPE reception 


Rel-7 




M 




5.3.1 .2.4.2 


Test case 1 : ANY CLOSE PIPE reception 


Rel-7 




M 




5.3.2.2 


Test case 1 : response to unknown command 


Rel-7 




M 




5.3.3.2 


Test case 1 : reception of unknown events 


Rel-7 




M 




5.4.2.1.1.2 


Test case 1 : SESSION IDENTITY 


Rel-7 




M 




5.4.2.1.1.3 


Test case 2: MAX PIPE 


Rel-7 




M 




5.4.2.1.1.4 


Test case 3: WHITELIST 


Rel-7 




M 




5.4.2.1.1.5 


Test case 4: HOST LIST 


Rel-7 




M 




5.4.2.3.1.2 


Test case 1 : registry parameters 


Rel-7 




M 




5.5.1.2.3 


Test case 2: valid pipe deletion from host to host 
controller 


Rel-7 




M 




5.5.1.3.2 


Test case 1 : identity reference data when 
TS 102 613 [2] is used 


Rel-7 




C101 




5.5.1.3.3 


Test case 2: reception of 

ADM CLEAR ALL PIPE - static pipes, dynamic 

pipes to host 


Rel-7 




M 




5.5.4.2 


Test case 1 : inhibited state 


Rel-7 




M 




5.5.4.3 


T ■ /"\ ■ 1 ■ 1 'i. 1 II £11 II 

Test case 2: inhibited state, followed by 
subsequent successful identity check 


Rel-7 




M 




5.5.5.2 


Test case 1 : processing of EVT POST DATA 


Rel-7 




M 




5.6.1 .2 


Test case 1 : RF gate of type A 


Rel-7 




M 




5.6.1 .3 


Test case 2: RF gate of type B 


D«l "7 

Kel-7 




M 




5.6.3.3.4.2.2 


Test case 1 : UID REG - default 


Rel-7 




M 




5.6.3.3.4.2.3 


Test case 2: SAK 


Rel-7 




M 




5.6.3.3.4.2.4 


Test case 3: ATS - default parameters 


Rel-7 




M 




5.6.3.3.4.2.5 


Test case 4: APPLICATION DATA 


Rel-7 




M 




5.6.3.3.4.2.6 


Test case 5: DATARATE MAX 


Rel-7 




M 




5.6.3.3.4.2.2 


Test case 1 : PUPI_REG - default 


Rel-7 




M 




5.6.3.3.4.2.3 


Test case 2: ATQB - verify the different parameter 


Rel-7 




M 




5.6.3.3.4.3.4 


Test case 3: HIGHER LAYER RESPONSE 


Rel-7 




M 




5.6.4.1.2 


Test case 1 : ISO/IEC 14443-3 [6] Type A - Full 
Power Mode 


Rel-7 




M 




5.6.4.1.3 


Test case 2: ISO/IEC 14443-3 [6] Type B 


Rel-7 




M 





Table 4.2 b): Conditional items referenced by table 4.2 a) 



Conditional item 


Condition 


Description 


C101 


IF 4.1/1 THEN M ELSE N/A 


O_102_613 



Table 4.2 c): Execution requirements referenced by table 4.2 a) 



Execution 
requirement 


Description 


SR1 


A gate which accepts dynamic pipe and has a RW registry parameter; the default value of the 
registry parameter must be known. 


TR1 


The DUT manufacturer has to provide information how the host controller can be powered down 
and powered up. 
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NOTE: Clause 4.5.2 should be referenced for the meaning and usage of the execution requirements which are 
described in table 4.2 c). 

4.3 Information to be provided by the device supplier 

The device supplier shall provide the information indicated in table 4.3. 



Table 4.3: Default configuration 



Item 


Description 


Presence/Value 


Status 


Mnemonic 


1 


Indication of presence of VERSION_SW, and value if supported. 




M 


V VERSION SW 


2 


Indication of presence of VERSION_HARD, and value if supported. 




M 


V VERSION HARD 


3 


Indication of presence of VENDOR_NAME, and value if supported. 




M 


V VENDOR NAME 


4 


Indication of presence of MODELJD, and value if supported. 




M 


V MODEL ID 


5 


Indication of presence of HCI VERSION, and value if supported. 




M 


V HCI VERSION 


6 


Value of GATES LIST 




M 


V GATES LIST 


7 


Value of MAX PIPE 




M 


V MAX PIPE 


8 


Value of HOST LIST 




M 


V HOST LIST 


NOTE: Conditional values shall be provided if the corresponding option is supported in the table 4.1 . 



4.4 Test equipment 

The test equipment shall provide a host simulator which is connected to the DUT during test procedure execution, 
unless otherwise specified. 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure that the value GATES_LIST is valid, according to the particular 
requirements of the test case being executed. 

With respect to the DUT, the host simulator shall comprise a valid host according to the specific DUT. The details are 
out of the scope of the present document. 

For some test cases, usage of a PCD is required. The detailed requirements are specified in the individual test cases. 

The test equipment shall ensure that a matching SYNC_ID is used during test case execution, unless otherwise 
specified. 

Some terminals might require the presence of an NAA (e.g. (U)SIM), which shall be provided by the test equipment. 

NOTE: The implementation of the terminal may imply certain activities or settings on the HCI layer. This should 
be taken into account when testing the HCI interface (e.g. PIPE state should be checked, activity after 
initialization, already open pipes, etc.). 

With respect to the DUT, the host simulator shall act as a valid host according to TS 102 622 [1] unless otherwise 
specified. In particular, the host simulator shall ensure before running a test case that all static pipes are closed, all 
dynamic pipes are deleted and the registry values are set to their defaults by running the sequence in table 4.4. 



Table 4.4: HCI test case initialization sequence 



Step 


Direction 


Description 


a1 


HS -» HCUT 


Send ANY OPEN PIPEonPIPEL 


a2 


HCUT^ HS 


Send ANY OK. 


a3 


HS -» HCUT 


Send ADM CLEAR ALL PIPE on PIPE1 with parameter ('FF FF). 


a4 


HCUT^ HS 


Send ANY OK. 



Before the execution of the RF technology test cases, RF gate parameters has to be modified properly to run the test. 

4.4.1 Measurement / setting uncertainties 

Void. 
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4.4.2 Default conditions for DUT operation 

Unless otherwise specified, the test equipment shall apply the default conditions described in the following clauses 
during test procedure execution. 

4.4.2.1 General 

The test equipment shall attempt to ensure that the identity check mechanism of the lower layer passes (see 
TS 102 622 [1], clause 8.4). 

If the test procedure indicates that the host simulator is to send ANY_OK in response to an ANY_OPEN_PIPE 
command, the parameter shall contain the number of pipes already open on the gate before the execution of the 
command. 

4.4.2.2 Status of UICC interfaces 

Void. 

4.4.3 Minimum/maximum conditions for DUT operation 

Void. 

4.4.4 Conventions 

Unless otherwise specified, ADM_CREATE_PIPE is sent by the test equipment with source H ID = H ID of host simulator 
and destination H ID = H ID of host controller. 

If the pipe for a response is not explicitly specified, then the pipe for the response is required to be the pipe on which the 
preceding command was sent. 

4.5 Test execution 

4.5.1 Parameter variations 

The test cases shall be carried out for the parameter variations specified individually for each test case. 

4.5.2 Execution requirements 

Table 4.2, Applicability of tests, specifies "execution requirements" for several test cases. For these test cases, it has not 
been possible to specify the corresponding test procedure in such a way that it can be guaranteed that the test procedure 
can be executed against every possible DUT. 

Some sample scenarios of test requirements are listed below: 

• The test case requires certain state to be present on the DUT in order to test a particular feature, but there is no 
mandatory requirement in the core specification (TS 102 622 [1]) for this state to be present. 

• The test case requires the DUT to perform a particular operation in order to test that feature, but the core 
specification (TS 102 622 [1]) does not provide a standardized mechanism to trigger that operation to be 
executed by the DUT. 

The test requirements have been split into various categories, as indicated by table 4.2 c): 

• Static requirements (SRx): information about, for example, particular gates or registry parameters which can 
be used in the test procedure execution. 

• Trigger requirements (TRx): mechanisms for triggering the DUT to perform certain operations. 

• Initial condition requirements (ICRx): information about how to establish initial condition states. 
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The DUT supplier should make every effort to provide appropriate information or mechanisms to allow these execution 
requirements to be satisfied for the DUT. 

It is recognized that this might not always be possible. For example, if the configuration of the DUT does not allow for 
the required state to be present; or if it is not possible to provide a particular trigger mechanism for the DUT. In these 
cases, it is acceptable that the test case is not carried out. However, it should be recognized that the consequence is that 
the particular feature will not be tested. 

4.6 Pass criterion 

A test shall only be considered as successful, if the test procedure was carried out successfully under all parameter 
variations with the DUT respecting all conformance requirements referenced in the test procedure. This is subject to the 
additional qualifications described in clause 4.6. 1 . 

NOTE: Within the test procedures, the RQs are referenced in the step where they are observable. In some cases, 
this is different from the step where they occur with respect to the DUT. 

4.6.1 Unanticipated behaviour from the DUT 

In the specification of the test procedures, every attempt has been made to ensure that the interface between the 
simulator and the DUT is in a known state before and during test procedure execution. However, as the DUT is an 
autonomous device, it is not possible to fully guarantee this. 

If the DUT unexpectedly closes or deletes a pipe which is intended to be used during a subsequent part of the test 
procedure, this should not be considered as a failure of the DUT, even though the test procedure cannot be completed 
successfully. Instead, the test procedure should be executed again to attempt to execute the test procedure to 
completion. If the unexpected behaviour occurs again, further effort should be applied by the tester to attempt to ensure 
that the unexpected behaviour does not occur. 



5 Test cases 

5.1 HCI architecture 

5.1.1 Overview 

Reference: TS 102 622 [1], clause 4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.1.2 Hosts 



Reference: TS 102 622 [1], clause 4.2. 



RQ4.1 


The host controller shall not use host identifiers which are RFU. 


RQ4.2 


The host controller shall reject received host identifiers which are RFU. 



NOTE 1: RQ4.1 is a non-occurrence RQ. 

NOTE 2: Development of test cases for RQ4.2 is FFS. 
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5.1.3 Gates 

5.1.3.1 Conformance requirements 



Reference: TS 102 622 [1], clause 4.3. 



RQ4.3 


The host controller shall have one administration gate. 


RQ4.4 


The host controller shall have one link management gate. 


RQ4.5 


The host controller shall have one identity management gate. 


RQ4.6 


The host controller shall have one loop back gate. 


RQ4.7 


The host controller shall not use gate identifiers which are RFU. 


RQ4.8 


The host controller shall reject received gate identifiers which are RFU. 


RQ4.9 


The host controller shall not use gate identifiers which are host specific but not yet allocated in 
TS 102 622[1]. 


RQ4.10 


The host controller shall reject received gate identifiers which are host specific but not yet allocated in 
TS 102 622 [1]. 



NOTE 1: RQ4.7 and RQ4.9 are not tested, as they are non-occurrence RQs. 
NOTE 2: Development of test cases for RQ4.10 is FFS. 

5.1 .3.2 Test case 1 : existence of gates 

5.1.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE0 is open. 

• PIPE1 is open. 



5.1 .3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send ANY_GET_PARAMETER(REC_ERROR) on PIPE0. 




2 


HCUT HS 


Send ANYOK (parameters are not checked). 


RQ4.4 










3 


HS HCUT 


Send ADM CREATE PIPE on PIPE1, with source and destination 
Gid = Gid of identity management gate. 




4 


HCUT HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 


RQ4.3, 
RQ4.5 


[ 5 


HS -» HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




6 


HCUT HS 


Send ANY OK. 


RQ4.5 










7 


HS HCUT 


Send ANY GET PARAMETER(GATES LIST) on PIPE ID MAN. 




8 


HCUT HS 


Send ANY OK. 

Check that the GATESJJST returned contains the Gid of the identity 
management gate and the Gid of the loop back gate. 


RQ4.5, 
RQ4.6 



5.1 .3.3 Test case 2: processing of RFU gate identifier 
5.1.3.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• Destination Gi D values of: Gi D value which is RFU as defined in TS 102 622 [1]. 
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5.1.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 



5.1 .3.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send A D M_C R E ATE P I P E on PIPE1 , with source Gid = Gid of identity 
management gate and the specified destination Gid. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ4.8 



5.1.4 Pipes 

5.1.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.4. 



RQ4.11 


The host controller shall not attempt to delete a static pipe. 


RQ4.12 


The host controller shall reject any attempts to delete a static pipe. 


RQ4.13 


The state of a pipe (i.e. open or closed) shall remain persistent if the hosts are powered down and up 
again. 


RQ4.14 


The state of a dynamic pipe after creation shall be closed. 


RQ4.15 


The initial state of a static pipe shall be closed. 


RQ4.16 


The host controller shall not use pipe identifiers which are RFU. 


RQ4.17 


The state of a pipe shall remain persistent if a host is temporarily removed from the host network and 
was not replaced by a different device in the meantime. 


RQ4.18 


For dynamic pipes, pipe identifiers are dynamically allocated by the host controller. 


RQ4.19 


All pipe identifiers allocated by the host controller for dynamic pipes shall be in the range '02' to '6F'. 


RQ4.20 


Dynamic pipe identifiers shall be unique in the host network. 



Reference: TS 102 622 [1], clauses 7.1.1.1. 
RQ7.2 |The registry of the host controller administration gate shall be persistent? 



Reference: TS 102 622 [1], clauses 8.1.1, 6.1.3.1 and 6.1.3.2. 



RQ8.3 


The host controller assigns an unused pipe identifier. 


RQ6.30 


When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADM_CREATE_PIPE command, with parameters as specified in TS 102 622 [1]. 


RQ8.7 


When a pipe is created towards the host controller then only steps 1 and 4 in figure 6 of TS 102 622 [1] 
are needed. 



NOTE 1: RQ4.11 and RQ4.16 are not tested, as they are non-occurrence RQs. 

NOTE 2: RQ4. 15 is not tested, as it is not clear when the initial state of the static pipe applies. 

NOTE 3: RQ4.18 is covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present document. 
This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.5.1.1. 

NOTE 4: RQ4. 19 and RQ4.20 are tested implicitly in different test cases in this test specification. 
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5.1 .4.2 Test case 1 : static pipe deletion 

5.1.4.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• PIPEO. 

• PIPE1. 

5.1.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 



5.1 .4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send ADM_DELETE_PIPE containing the pipe indicated in the test execution 
clause, on PIPE1. 




2 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ4.12 



5.1 .4.3 Test case 2: initial pipe state and persistence of pipe state and registry value 

5.1 .4.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.1.4.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 

• The value of SESSION_IDENTITY in the registry is not 'FFFFFFFFFFFFFFFF. 
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5.1 .4.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


o _ « _i Ann /~v r- 1 1 — ati — n i ni — _„ nini — a ...:.■.(_ /~» 1 1 — i — i _ „ _i 

Send ADM_CREATE_PIPE on PIPE1 , with source Gid = EE and 
destination Gid = Gid of the loop back gate. 




2 


HCUT HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE LOOP BACK. 




3 


HS -» HCUT 


Open PIPE on PIPE LOOP BACK. 




4 


HCUT HS 


Send ANY OK. 




5 


HS -» HCUT 


bend AUM_(_/KtA I tPIrt on rlPtl , with source Gid = 00 and 
destination Gid = Gid of identity management gate. 








Send ANY OK, with parameters of 5 bytes as follows: 


RQ4.14, 






• Source Hid = Hid of host simulator. 


HU4.1 o, 






• Source Gid = source Gid in command. 




6 


HCUT -> HS 


• Destination H| D = destination H| D in command. 

• Destination Gid = destination Gid in command. 

• Pid = a previously unallocated Pid- 
Designate the create pipe PIPE_ID_MAN. 


nvjo.ou, 

RQ8.7 


7 


HS -» HCUT 


Send ANY_GET_PARAMETER(GATES_LIST) on (PIPEJD MAN). 




8 


HCUT HS 


Send response containing an allowed error response code for the 
command. 


RQ4.14 


9 


User -> 


Trigger both the host controller and the host simulator to be powered 






HCUT 


down. 




10 


1 1 1 IT X 1 1 f"N 

HCUT -> HS 


Power down the host simulator. 




1 1 


II 1 it 

HCUT 


Powered down. 




12 


User -> 

II /-^ I IT 

HOU 1 


Trigger both the host controller and the host simulator to be powered up. 




13 


HCUT 


Powered up. 




14 


1 1 1 IT X 1 1 fX 

HCUT -> HS 


Power up the host simulator. 




15 


1 1 O XII 1 IT 

HS -> HCUT 


fx_ i a k i \ / /™» i — 1~ r~\ a n a it a i — i~i — n /ni — o o i /"\ k i i rx i — h itit\/\ nini — a 

Send ANY GET PARAMETER (SESSION IDENTITY) on PIPE1. 




16 


HCUT HS 


Send ANY_OK, with parameter value equal to the parameter value before 
the terminal was powered down. 


RQ7.2 


I / 


UIQ UPI IT 
no ✓ riL/U 1 


QonH AMV C*\ HQP PIPE r»n PIPP1 

oena min Y uluoc nrc on nrc I . 




18 


HCUT HS 


Send ANY OK. 


RQ4.13 


19 


HS HCUT 


Send ANY_GET_PARAMETER(GATES_LIST) on PIPE_ID_MAN. 




20 


HCUT HS 


Send response containing an allowed error response code for the 
command. 


RQ4.13 


21 


HS -» HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




22 


HCUT HS 


Send ANY OK. 


RQ4.13 


23 


HS HCUT 


Send EVT POST DATA on PIPE LOOP BACK. 




24 


HCUT HS 


SendEVT POST DATA on PIPE LOOP BACK. 


RQ4.13 



5.1.5 Registries 

5.1.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 4.5. 



RQ4.21 


For all gates defined in TS 102 622 [1], parameter identifiers in the range of '00' to 'EF' are reserved for 
use in TS 102 622 [1]. 


RQ4.22 


A new instance of the registry is created for every pipe that connects to the gate. 


RQ4.23 


Upon pipe creation all registry parameters with access rights Read-write (RW) or Write-only (WO) shall 
be set to their default values. 


RQ4.24 


Upon pipe creation all read-only (RO) parameters shall be set by the entity managing the registry to an 
appropriate value which may differ from the default values. 


RQ4.25 


When a pipe is deleted its registry instance is also deleted. 


RQ4.26 


Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



NOTE 1: As the specification of registry parameters is specific to each individual registry, RQ4.21, RQ4.23 and 
RQ4.24 are not tested in this clause, but are tested in other clauses of the present document for each 
individual registry. 
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NOTE 2: RQ4.22 is not currently tested as TS 102 622 [1] does not specify any gates with the required properties 
to exercise this functionality. 

NOTE 3: Development of test cases for RQ4.26 is FFS. 

5.1 .5.2 Test case 1 : registry deletion 

5.1.5.2.1 Test execution 

Assignment of terms to entities referenced in SRI: G ID of gate = GATE_X, registry parameter identifier = 
REG_PARAM. 

There are no test case-specific parameters for this test case. 

5.1.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 



5.1 .5.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ADM CREATE PIPE on PIPE1 , with source Gid = 'EE' and destination 
Gid = GATEX. 




2 


HCUT HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPEa. 




3 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HCUT^ HS 


Send ANY OK. 




5 


HS -» HCUT 


Send ANY_SET_PARAMETER(REG_PARAM) on PIPEa, with a value 
different from the default value. 




6 


HCUT HS 


Send ANY OK (parameters are not checked). 




7 


HS^ HCUT 


Send ADM_DELETE_PIPE(PIPEa) on PIPE1. 




8 


HCUT^ HS 


Send ANY OK (parameters are not checked). 




9 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with Gid = GAT EX. 




10 


HCUT HS 


Send ANY OK (parameters are not checked); designate the created pipe 

PIPED. 

(The Pid used for PIPEb may be the same as or may be different from the Pid 
used for PIPEa.) 




11 


HS^ HCUT 


Send ANY OPEN PIPE on PIPEb. 




12 


HCUT^ HS 


Send ANY OK. 




13 


HS -» HCUT 


Send ANY_GET_PARAMETER(REG_PARAM) on PIPEb. 




14 


HCUT HS 


Send ANY OK with parameter value equal to the default value of 
REG_PARAM. 


RQ4.25 
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5.2 HCP 

5.2.1 HCP packets 

5.2.1.1 Conformance requirements 



Reference: TS 102 622 [1], clause 5.1. 



RQ5.1 


The host controller shall use the correct structure for transmitted HCP packets. 


RQ5.2 


The host controller shall recognize correctly structured received HCP packets. 


RQ5.3 


When receiving a packet, the host controller as destination host forwards the packet to the destination 
gate. 


RQ5.4 


When it receives a packet from a host, the host controller uses the value of P, D to forward a packet to the 
destination host. 


RQ5.5 


When it receives a packet from a host, the host controller shall verify that the pipe identifier is used by a 
host involved in the creation of the pipe. 



NOTE 1 : RQ5. 1 and RQ5.2 are implicitly tested by the testing of higher layers in other clauses of the present 
document. 

NOTE 2: RQ5.3 is internal to the host controller, and is not tested in this clause. It will be implicitly tested in many 
other test cases within the current document. 

NOTE 3: RQ5.4 and RQ5.5 are tested in clause 5.5.1.1.2 of the TS 102 695-3 [10]. 

5.2.2 HCP message structure 
5.2.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 5.2. 



RQ5.6 


The host controller shall use the correct structure for transmitted HCP messages. 


RQ5.7 


Type value 3 shall not be used. 


RQ5.8 


The host controller shall recognize correctly structured received HCP messages. 


RQ5.9 


A gate shall only accept a command or an event on a pipe when the state of that pipe is open unless 
otherwise stated. 


RQ5.10 


A gate shall not send a command or event on a pipe when it is waiting for a response to a previous 
command on that pipe unless otherwise stated. 



NOTE 1: RQ5.6 and RQ5.8 are implicitly tested by the testing of higher layers in other clauses of the present 
document. 

NOTE 2: RQ5.7 and RQ5.10 are not tested, as they are non-occurrence RQs. 

5.2.2.2 Test case 1 : commands/events on pipe which is not open 

5.2.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.2.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 
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5.2.2.2.3 Test procedure 



Step 


Direction 


Description 


rx /"\ 

RQ 


1 


HS HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination Gid = Gid 
of identity management gate. 




2 


HCUT HS 


Send ANY_OK (parameters are not checked); designate the created pipe 

D I DC MAM 

PIPE IU MAN. 




3 


HS -» HCUT 


Send ANY_OPEN_PIPE on PIPE_ID_MAN. 




4 


1 1 /-X 1 IT X l_IO 

HCUT -> HS 


Send ANY OK. 




5 


HS HCUT 


Send ANY_GET_PARAMETER(GATES_LIST) on PIPE_ID_MAN. 




6 


1 1 1 IT X 1 1 

HCUT -> HS 


Send ANY_OK (parameters are not checked). 


RQ5.9 


7 


1 1 X II /~\ 1 IT 

HS -> HCUT 


rx _ i a h i \ / /x i /"Xfx i — rx i rx i — rx i rx i — i rx n a a n i 

Send ANY CLOSE PIPE on PIPE ID MAN. 




8 


1 1 /~i 1 IT X 1 1 

HCUT -> HS 


Send ANY_OK (parameters are not checked). 




9 


1 1 (~1 X II /~\ 1 IT 

HS HCUT 


/x i a k i \ i /*"x r~ -t~ rx a aki i~~ "t" i~~ rx / /*x a "~ r~ i~ /x i i r> — i— \ rx i rx i - i rx h A a k i 

Send ANY_GET_PARAMETER(GATES_LIST) on PIPE ID MAN. 




10 


1 1 /"^ 1 IT X 1 1 

HCUT -> HS 


Send response containing an allowed error response code for the command. 


RQ5.9 


11 


HS HCUT 


/x _ ._ _i a rx h a /x rx r~ a ~r~ r~ rx i rx i~~ .. rx i rx r - ^ . > . : x i. ........ /^x i r - r-~ • . .. _i _j..±:.. . x : . .. 

Send ADM_CREATE_PIPE on PIPE1 , with source Gid = EE and destination 
Gid = Gid ot the loop back gate. 




12 


HCUT HS 


Send ANY_OK (parameters are not checked); designate the created pipe 

rlrt LUUr bAL>l\. 




1 o 


|_| O _x |_|p| IT 

no ^7 nou 1 


Qonrl AMV PlPFM PIPP on PIPP 1 OOP RAf^K 
oena MINT LJrdN rlrC On rlrC Lwwr BRL»r\. 




14 


HCUT^ HS 


Send ANY OK. 




15 


HS HCUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




16 


HCUT^ HS 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 


RQ5.9 


17 


HS -» HCUT 


Send ANY_CLOSE_PIPE on PIPE_LOOP_BACK. 




18 


HCUT^ HS 


Send ANY OK (parameters are not checked). 




19 


HS^ HCUT 


Send EVT POST DATA containing '01 02 03 04' on PIPE LOOP BACK. 




20 


HS HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




21 


HCUT^ HS 


Send ANY OK. 


RQ5.9 



5.2.3 Message fragmentation 
5.2.3.1 Conformance requirements 



Reference: TS 102 622 [1], clause 5.3. 



RQ5.11 


Message fragmentation shall be used when the size of the message is larger than supported by the 
underlying data link layer. 


RQ5.12 


Messages shall be fragmented according to the rules specified in TS 102 622 [1]. 


RQ5.13 


The destination gate is responsible for rebuilding the message from the fragmented messages. 


RQ5.14 


If a reset of the underlying data link layer occurs, fragments of a partially received message shall be 
discarded and a partially sent message shall be re-sent from the beginning. 



NOTE: Development of test cases for RQ5.11, RQ5.12, RQ5.13 and RQ5.14 is FFS. 
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5.3 Instructions 

5.3.1 Commands 

5.3.1.1 Overview 

5.3.1 .1 .1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.1.1. 



RQ6.1 


For all gates, the host controller shall not use RFU instruction values ('05' to 'OF') in commands. 


RQ6.2 


For administration gates, the host controller shall not use RFU instruction values ('16' to '3F') in 
commands. 


RQ6.3 


For gates defined in TS 1 02 622 [1 ], the host controller shall not use instruction values between '1 0' and 
'3F' which are not allocated in TS 102 622 [1]. 



NOTE: RQ6. 1, RQ6.2 and RQ6.3 are not tested, as they are non-occurrence RQs. 

5.3.1.2 Generic commands 
5.3.1.2.1 ANYSETPARAMETER 
5.3.1.2.1.1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.1.2.1. 



RQ6.4 


The host controller shall reject an incorrectly formatted ANY_SET_PARAMETER command with an 
allowed error response code. 


RQ6.5 


The host controller shall reject an ANY_SET_PARAMETER command if the access right for the 
parameter does not allowed writing (i.e. is not RW or WO). 


RQ6.6 


The host controller shall not send an ANY_SET_PARAMETER command if the access right for the 
parameter does not allow writing (i.e. is not RW or WO). 


RQ6.7 


When the host controller receives a valid ANY_SET_PARAMETER command, it shall write the 
parameter value into the registry and respond with ANY_OK without any parameters. 


RQ6.8 


Whenever the host controller sends an ANY_SET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have at least one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 

• The parameter value shall be a valid value as defined for the specific gate. 



NOTE 1: RQ6.6 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ6.7 and RQ6.8 are not tested in this clause, as they are effectively tested in other clauses of the present 
document for each individual registry parameter. 

NOTE 3: Test cases for RQ6.5 and RQ6.4 are presented in TS 102 695-3 [10]. 
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5.3.1.2.2 ANYGETPARAMETER 
5.3.1.2.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.1.2.2. 



RQ6.9 


The host controller shall reject an incorrectly formatted ANY_GET_PARAMETER command with an 
allowed error response code. 


RQ6.10 


The host controller shall reject an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 


RQ6.11 


The host controller shall not send an ANY_GET_PARAMETER command if the access right for the 
parameter does not allowed reading (i.e. is not RW or RO). 


RQ6.12 


When the host controller receives a valid ANY_GET_PARAMETER command, it shall shall respond with 
ANY_OK with the value of the parameter. 


RQ6.13 


Whenever the host controller sends an ANY_GET_PARAMETER command, it shall do so correctly: 

• It shall only be sent to a gate which supports the command. 

• It shall always have exactly one byte in the command parameters. 

• The parameter identifier shall match one of those defined for the specific gate. 



NOTE 1: RQ6.11 is not tested, as it is a non-occurrence RQ. 

NOTE 2: RQ6.12 and RQ6.13 are not tested, as they are effectively tested in other clauses of the present document 
for each individual registry parameter. 

NOTE 3: Test cases for RQ6.10 and RQ6.9 are presented in TS 102 695-3 [10]. 
5.3.1.2.3 ANY_OPEN_PIPE 
5.3.1.2.3.1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.1.2.3. 



RQ6.14 


The host controller shall reject an incorrectly formatted ANY_OPEN_PIPE command. 


RQ6.15 


When the host controller receives a valid ANY_OPEN_PIPE command on a closed pipe, it shall open the 
pipe and return ANY OK without any parameter. 


RQ6.16 


When the host controller sends an ANY_OPEN_PIPE command, it shall contain no command 
parameters. 


RQ6.17 


When the host controller receives ANY_OK in response to an ANY_OPEN_PIPE command, it shall open 
the pipe. 



NOTE 1: In TS 102 622 [1], it is not specified whether ANY_OPEN_PIPE is valid over a pipe which is already 
open. This is therefore not listed as a conformance requirement. 

NOTE 2: Test cases for RQ6.16 and RQ6.17 are presented in TS 102 695-3 [10]. 
5.3.1 .2.3.2 Test case 1 : ANY_OPEN_PIPE reception 

5.3.1.2.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1 .2.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 
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Step 


Direction 


Description 


RQ 


\ 


UIC Uf"*l IT 

no s nOU 1 


C Q nH AMV 1^1 flCC PIPP nn PIPP1 

oGnOANY OLUot rlrt Oil rlrtl. 




2 


HCUT^ HS 


Send ANYOK. 




o 

o 


ljo _x ur^\ ix 
Mb -7 HOU 1 


bend AN Y_UrbN_rlrb Wlln parameter UU On rlrbl. 




4 


HCUT HS 


Send response containing an allowed error response code for the 

pnmmanrl 

LUI I II I Idl IU . 


KUb.14 


5 


HS -» HCUT 


Send ANY OPEN PIPEonPIPEL 




6 


HCUT^ HS 


Send ANY OK with no parameters. 


RQ6.15 


7 


HS HCUT 


Send ADMCREATEPIPE on PIPE1, with source and destination 
Gid = Gid of identity management gate. 




8 


HCUT HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 




9 


HS -» HCUT 


Send ANY OPEN PIPE on PIPE ID MAN. 




10 


HCUT^ HS 


Send ANY OK with no parameters. 


RQ6.15 



5.3.1.2.4 ANY_CLOSE_PIPE 

5.3.1.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.2.4. 



RQ6.18 


The host controller shall reject an incorrectly formatted ANY_CLOSE_PIPE command. 


RQ6.19 


When the host controller receives a valid ANY_CLOSE_PIPE on an open pipe, it shall close the pipe and 
respond with ANY_OK and no parameters. 


RQ6.20 


When the host controller sends an ANY_CLOSE_PIPE command, it shall contain no command 
parameters. 


RQ6.21 


When the host controller receives ANY_OK in response to an ANY_CLOSE_PIPE command, it shall 
close the pipe. 



NOTE: Test cases for RQ6.20 and RQ6.21 are presented in TS 102 695-3 [10]. 
5.3.1 .2.4.2 Test case 1 : ANY_CLOSE_PIPE reception 

5.3.1.2.4.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.1 .2.4.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 



5.3.1 .2.4.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ANY_CLOSE_PIPE with parameter '00' on PIPE1 . 




2 


HCUT ^ HS 


Send response containing an allowed error response code for the 
command. 


RQ6.18 


3 


HS^ HCUT 


Send ADM_CREATE_PIPE on PIPE1, with source and destination 
Gid = Gid of identity management gate. 




4 


HCUT ^ HS 


Send ANY OK (parameters are not checked); designate the created pipe 
PIPE ID MAN. 




5 


HS^ HCUT 


Send ANY_CLOSE_PIPE on PIPE1 . 




6 


HCUT^ HS 


Send ANY_OK with no parameters. 


RQ6.19 


7 


HS ^ HCUT 


Send ADM CREATE PIPE on PIPE1, with source and destination 
Gid = Gid of identity management gate. 




8 


HCUT ^ HS 


Send response containing an allowed error response code for the 
command. 


RQ6.19 
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5.3.1.3 



Administration commands 



5.3.1.3.1 



ADM CREATE PIPE 



5.3.1.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.1. 



RQ6.22 



When the host controller receives an ADM CREATE PIPE command, it shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 



RQ6.23 



When the pipe was successfully created, the host controller shall send the response ANY_OK in 
response to the ADM_CREATE_PIPE command, with parameters as specified in TS 102 622 [1], 



NOTE: All conformance requirements for the referenced clause are included in clauses 5.5.1.1 and 5.1.4.3 of the 
present document. 



5.3.1.3.2 



ADM NOTIFY PIPE CREATED 



5.3.1.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.2. 



RQ6.24 



When the host controller sends an ADMNOTIFYPIPECREATED command, the command 
parameters shall be 5 bytes long. 



RQ6.25 



When the host controller sends an ADM NOTIFY PIPE CREATED command as a result of an 
ADM_CREATE_PIPE command being received from a host, the source Hid in the command 
parameters shall be the H| D of that host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.1 of the present 
document. 



5.3.1.3.3 



ADM DELETE PIPE 



5.3.1.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.3. 



RQ6.26 



The host that requested the deletion of the pipe can only be the source host or destination host. 



RQ6.27 



When the pipe is successfully deleted, the host controller shall send the response ANY_OK without 
parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.2 of the present 
document. 



5.3.1.3.4 



ADM NOTIFY PIPE DELETED 



5.3.1.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.4. 



RQ6.28 



When the host controller sends an ADM_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.2 of the present 
document. 
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5.3.1.3.5 ADMCLEARALLPIPE 
5.3.1.3.5.1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.1.3.5. 



RQ6.29 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as 
the identity reference data, and shall use the identity reference data to initialize the reference data 
used by the host controller to check the UICC host identity. 


RQ6.30 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting 
host and set all registry values related to static pipes connected to the requesting host to their 
default values. 


RQ6.31 


When ADM_CLEAR_ALL_PIPE is successful the host controller shall respond with an ANY_OK 
without parameters. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5.1.3 of the present 
document. 

5.3.1 .3.6 ADMNOTIFYALLPIPECLEARED 

5.3.1.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.1.3.6. 



RQ6.32 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting 
host, it shall send ADM NOTIFY ALL PIPE CLEARED to every host with at least one pipe to the 
requesting host. 


RQ6.33 


When the host controller sends an ADM NOTIFY ALL PIPE CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and 
the host and shall close all static pipes between the host and the host controller. 


RQ6.34 


When the host controller sends an ADM NOTIFY ALL PIPE CLEARED command, the command 
parameters shall be one byte long and shall contain the H| D of the requesting host. 



NOTE: All conformance requirements for the referenced clause are included in clause 5.5. 1 .3 of the present 
document. 

5.3.2 Responses 

5.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 6.2. 



RQ6.35 


A response shall be sent to all commands received even to those unknown to the receiving gate. 


RQ6.36 


Responses received out of order (i.e. if no command was sent previously) shall be discarded. 


RQ6.37 


For a received command which is defined in Table 16 in TS 102 622 [1], the host controller shall only 
return a response code which is specified for that command in Table 16 in TS 102 622 [1]. 



NOTE 1 : Development of test cases for RQ6.37 is FFS. 

NOTE 2: Test cases for RQ6.36 are presented in TS 102 695-3 [10]. 

5.3.2.2 Test case 1 : response to unknown command 
5.3.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 
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5.3.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 



• PIPE1 is open. 

5.3.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send command with an RFU instruction value on PIPE1 . 




2 


HCUT^ HS 


Send response (contents are not checked). 


RQ6.35 



5.3.3 Events 

5.3.3.1 Conformance requirements 



Reference: TS 102 622 [1], clause 6.3. 



RQ6.38 


Unknown events received shall be discarded. 


RQ6.39 


EVT_HOT_PLUG shall be sent by the host controller to any other connected host to notify the 
connection or disconnection of a host to the host controller. 


RQ6.40 


When the host controller send EVT_HOT_PLUG, it shall contain no parameters. 


RQ6.41 


For gates defined in TS 102 622 [1], the host controller shall not use event values which are not allocated 
in TS 102 622 [1]. 



NOTE 1: RQ6.41 is not tested, as it is a non-occurrence RQ. 
NOTE 2: Development of test cases for RQ6.39 and RQ6.40 is FFS. 

5.3.3.2 Test case 1 : reception of unknown events 

5.3.3.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.3.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 



• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 

5.3.3.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send event with an RFU instruction value on PIPE ID MAN. 




2 


HS^ HCUT 


Send ANY_GET_PARAMETER(GATES_LIST) on PIPE_ID_MAN. 




3 


HCUT^ HS 


Send response with ANY OK and value of GATESJJST. 


RQ6.38 
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5.4 GATES and subclauses 

5.4.1 GATES 

5.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7. 
|RQ7.1 |Gates shall support the commands and events specified for them in tables 18 and 19 of TS 102 622 [1]. | 

NOTE 1: RQ1 is not tested in this clause, as it is effectively tested in other clauses of the present document. 

NOTE 2: AN Y_GET_P AR AMETER and ANY_SET_PARAMETER are not tested in this clause, as they are 
tested in the specific clauses for each gate for testing registry parameters. 

NOTE 3: ADM_CREATE_PIPE, ADM_DELETE_PIPE and ADM_CLEAR_ALL_PIPE are not tested for the host 
controller administration gate, as they are tested in the specific clauses for each command. 

NOTE 4: EVT_POST_DATA is not tested for the loop back gate, as it is tested in the clause 5.5.5. 

NOTE 5: EVT_HCI_END_OF_OPERATION is not tested for the host controller link management gate, as the 
reaction of the host controller is not specified in TS 102 622 [1]. 

5.4.2 Management gates 
5.4.2.1 Administration gates 

5.4.2.1 .1 Host controller administration gate 

5.4.2.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.1.1 and 4.5. 



RQ4.26 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not defined in 
TS 102 622 [1] shall not be present in the registry. 


RQ6.32 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting host, it shall 
send ADM NOTIFY ALL PIPE CLEARED to every host with at least one pipe to the requesting host. 


RQ7.2 


The registry of the host controller administration gate shall be persistent. 


RQ7.3 


The host controller shall use a default value for SESSION IDENTITY of 'FFFFFFFFFFFFFFFF'. 


RQ7.4 


The host controller shall apply the access condition of RW to SESSIONJDENTITY. 


RQ7.5 


The host controller shall only accept values of SESSION IDENTITY of length 8 bytes. 


RQ7.6 


The host controller shall use a default value for MAX PIPE of between '10' and '7D' inclusive. 


RQ7.7 


The host controller shall apply the access condition of RO to MAX_PIPE. 


RQ7.8 


The host controller shall allow MAX_PIPE created dynamic pipes for the host. 


RQ7.9 


The host controller shall use a default value for WHITELIST of an empty array. 


RQ7.10 


The host controller shall apply the access condition of RW to WHITELIST. 


RQ7.11 


The host controller shall use a default value for HOSTJJST containing the list of the hosts that are accessible 
from this host controller including the host controller itself, as a list of host identifiers. 


RQ7.12 


The host controller shall apply the access condition of RO to HOSTJJST. 


RQ7.13 


The HOSTJJST shall contain the list of the hosts that are accessible from this host controller including the host 
controller itself. 


RQ7.14 


The host controller shall reject create pipe requests if the source host is not listed in the WHITELIST of the 
destination host. 



NOTE 1: Development of test cases for RQ4.26 and RQ7.8 is FFS. 
NOTE 2: RQ7.13 is only tested in the context of RQ7.11 (i.e. default value). 

NOTE 3: RQ7.14 is also covered in clause 8.1.1 of TS 102 622 [1], covered by clause 5.5.1.1 of the present 

document. This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.5.1.1. 
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NOTE 4: RQ7.2 is tested in clause 5.1.4.3 of the present document. 
5.4.2.1 .1 .2 Test case 1 : SESSIONJDENTITY 

5.4.2.1.1.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 



5.4.2.1.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ADMCLEARALLPIPE on PIPE1 with appropriate parameter as 
required by the lower layer. 




2 


HCUT HS 


Send ANY OK. 




3 


HS HCUT 


Send ANY_OPEN_PIPE on PIPE1 . 




4 


HCUT HS 


Send ANY OK (parameters are not checked) 




I 5 


HS HCUT 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE1. 




6 


HCUT HS 


Send ANY_OK with parameter value 'FFFFFFFFFFFFFFFF'. 


RQ7.3, 
RQ7.4 


7 


HS HCUT 


Send ANY SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPE1. 




8 


HCUT^ HS 


Send ANY OK. 


RQ7.4 


9 


HS -» HCUT 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE1. 




10 


HCUT HS 


Send ANY OK with parameter value '01 02 03 04 05 06 07 08'. 


RQ7.4 


11 


HS HCUT 


Send ANY SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 
07') on PIPE1. 




12 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ7.5 



5.4.2.1.1.3 Test case 2: MAX_PIPE 

5.4.2.1.1.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 



5.4.2.1.1.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ADM CLEAR ALL PIPE on PIPE1 with appropriate parameter as 
required by the lower layer. 




2 


HCUT^ HS 


Send ANY OK. 


RQ6.32 


3 


HS HCUT 


Send ANY OPEN PIPEonPIPEL 




4 


HCUT HS 


Send ANY OK. 




5 


HS HCUT 


Send ANYGETPARAMETER(MAXPIPE) on PIPE1. 




6 


HCUT HS 


Send ANY OK with parameter value V_ MAX_PIPE. 


RQ7.6, 
RQ7.7 


7 


HS HCUT 


IfV MAX PIPE = '10', send ANY SET PARAMETER(MAX PIPE, '11') on 
PIPE1. 

Otherwise send ANY_SET_PARAMETER(MAX_PIPE, '10') on PIPE1. 




8 


HCUT HS 


Send response containing an allowed error response code for the command. 


RQ7.7 



ETSI 



Release 7 32 ETSI TS 1 02 695-1 V7.0.0 (201 0-04) 

5.4.2.1.1.4 Test case 3: WHITELIST 

5.4.2.1.1.4.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.4.2 Initial conditions 

The last value of WHITELIST in the host controller's registry is not an empty array. 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 



5.4.2.1.1.4.3 Test procedure 



Step 


Direction 


Description 


RQ j 


1 


HS HCUT 


Send ADMCLEARALLPIPE on PIPE1 with appropriate parameter as 
required by the lower layer. 




2 


HCUT^ HS 


Send ANY OK. 




3 


HS -» HCUT 


Send ANY OPEN PIPEonPIPEL 




4 


HCUT^ HS 


Send ANY OK . 




5 


HS -» HCUT 


Send ANY_GET_PARAMETER(WHITELIST) on PIPE1. 




6 


HCUT^ HS 


Send ANY_OK with a parameter of length zero. 


RQ7.9, 
RQ7.10 


7 


HS HCUT 


Send ANY SET PARAMETER(WHITELIST, '01') on PIPE1. 




8 


HCUT^ HS 


Send ANY OK 


RQ7.10 


9 


HS HCUT 


Send ANY_GET_PARAMETER(WHITELIST) on PIPE1. 




10 


HCUT^ HS 


Send ANY_OK with parameter value '01 '. 


RQ7.10 



5.4.2.1 .1 .5 Test case 4: HOSTJJST 

5.4.2.1.1.5.1 Test execution 

There are no test case-specific parameters for this test case. 

5.4.2.1.1.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 



5.4.2.1.1.5.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ADM CLEAR ALL PIPE on PIPE1 with appropriate parameter as 
required by the lower layer. 




2 


HCUT HS 


Send ANY OK. 




i 3 


HS HCUT 


Send ANY OPEN PIPEonPIPEL 




4 


HCUT HS 


Send ANY OK 




5 


HS HCUT 


Send ANY_GET_PARAMETER(HOST_LIST) on PIPE1. 










RQ7.11, 


6 


HCUT HS 


Send ANY OK with parameter value VJHOSTJJST. 


RQ7.12, 
RQ7.13 


7 


HS HCUT 


Send ANY_SET_PARAMETER(HOST_LIST, '00') on PIPEL 




8 


HCUT^ HS 


Send response containing an allowed error response code for the command. 


RQ7.12, 
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5.4.2.1 .2 Host administration gate 

5.4.2.1.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.1.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.4.2.2 Link management gate 

5.4.2.2.1 Host controller link management gate 

5.4.2.2.1.1 Conformance requirements 



Reference: TS 102 622 [1], clauses 7.1.2.1 and 4.5. 



RQ4.26 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 


RQ7.15 


The host controller shall use a default value for REC_ERROR of '0000'. 


RQ7.16 


The host controller shall apply the access condition of RW to REC_ERROR. 


RQ7.17 


The host controller shall only accept values of REC_ERROR of length 2 bytes. 



NOTE 1 : Development of test cases for RQ4.26 is FFS. 

NOTE 2: Test cases for RQ7.15, RQ7.16 and RQ7.17 are presented in TS 102 695-3 [10]. 

5.4.2.2.2 Host link management gate 

5.4.2.2.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.2.2. 
|RQ7.18 |The host controller shall only set values of REC_ERROR with length 2 bytes. 

NOTE: Test cases for RQ7. 18 are presented in TS 102 695-3 [10]. 

5.4.2.3 Identity management gate 
5.4.2.3.1 Local registry 

5.4.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.3 and 4.5. 



NOTE 1: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
local registry. The requirements for the remote registry are contained in clause 5.4.2.3.2. 



RQ4.26 


Registry parameters which are in the range of '00' to 'EF' but which are not allocated in 
TS 102 622 [1] shall not be present in the registry. 


RQ7.19 


The registry of the identity management gate shall be persistent. 


RQ7.20 


This gate shall be provided by all hosts and the host controller. 


RQ7.21 


If present in the host controller, the host controller shall use a value for VERSION_SW of length 
3 bytes. 


RQ7.22 


If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION SW. 


RQ7.23 


If present in the host controller, the host controller shall use a value for VERSlON_HARD of length 
3 bytes. 


RQ7.24 


If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION HARD. 
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RQ7.25 


1 £ J.*J.I 1 J. ■ | | j.1 1 ■ ill III 1 .IWI — 1 — * |~» | /*"\ k 1 1 1 n K II — r 

If present in the host controller, the host controller shall use a value for VERSION_NAME of 
maximum length 20 bytes with UTF8 coding. 


RQ7.26 


If present in the host controller, the host controller shall apply the access condition of RO to 
VERSION NAME. 


RQ7.27 


If present in the host controller, the host controller shall use a value for MODEL ID of length 1 byte. 


RQ7.28 


II 1 1 1 1 1 i a || | ± ill III III I'i" f |-~» .-"V . 

If present in the host controller, the host controller shall apply the access condition of RO to 
MODEL ID. 


RQ7.29 


If present in the host controller, the host controller shall apply the access condition of RO to 
HCI VERSION. 


RQ7.30 


The host controller shall use a value for GATES_LIST containing the list of all gates that accept 
dynamic pipes as an array of gate identifiers. 


RQ7.31 


The host controller shall apply the access condition of RO to GATESJJST. 


RQ7.32 


A host controller according to the present document shall set the HCI_VERSION parameter if 
provided to '01'. 



NOTE 2: Development of test cases for RQ4.26 is FFS. 

NOTE 3: RQ7. 19 is not tested within this clause, as the registry contains no writeable parameters which can be 
used to test the persistence of the registry. 

NOTE 4: RQ7.20 is also covered in clause 4.3 of TS 102 622 [1], covered by clause 5.1.3 of the present document. 
This RQ is therefore not tested within this clause, as it is effectively tested in clause 5.1.3. 

NOTE 5: Test cases for RQ7.21, RQ7.22, RQ7.23, RQ7.24, RQ7.25, RQ7.26, RQ7.27 and RQ7.28 are presented in 
TS 102 695-3 [10]. 

5.4.2.3.1 .2 Test case 1 : registry parameters 

5.4.2.3.1.2.1 Test execution 



The test procedure shall be executed for each of the parameters in the following table. 



Registry parameter 

(designated REG PARAM) 


Presence 


Expected value 

(designated VALUE) 


RQ to be checked in 
steps 2 and 6 


RQ to be checked 
in step 4 


HCI VERSION 


O 


V HCI VERSION 


RQ7.32 


RQ7.29 


GATES LIST 


M 


V GATES LIST 


RQ7.30 


RQ7.31 



5.4.2.3.1 .2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_ID_MAN) has been created to the host controller's identity management gate, and is open. 



5.4.2.3.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 j 


HS HCUT 


Send ANY_GET_PARAMETER(REG_PARAM) on PIPE_ID_MAN. 




2 


HCUT HS 


If REG_PARAM is supported by the device under test as indicated in 

table 4.3, send ANY_OK with parameter value equal to VALUE. 

If REG_PARAM is not supported by the device under test as indicated in 

table 4.3, send response containing an allowed error response code for the 

command. 


See test 
execution 
clause 
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5.4.2.3.2 Remote registry 

5.4.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 7.1.3. 

NOTE 1: This clause covers the conformance requirements contained within TS 102 622 [1], clause 7.1.3 for the 
remote registry. The requirements for the local registry are contained in clause 5.4.2.3.1. 



RQ7.33 


The host controller shall adhere to the access condition of RO for VERSION SW in the host. 


RQ7.34 


The host controller shall adhere to the access condition of RO for VERSION HARD in the host. 


RQ7.35 


The host controller shall adhere to the access condition of RO for VERSION NAME in the host. 


RQ7.36 


The host controller shall adhere to the access condition of RO for MODEL ID in the host. 


RQ7.37 


The host controller shall adhere to the access condition of RO for HCI VERSION in the host. 


RQ7.38 


The host controller shall adhere to the access condition of RO for GATESJJST in the host. 


RQ7.39 


The host controller shall manage backward compatibility with previous HCI versions and use only 
commands and parameters defined in the specification having the lower HCI version number between of 
the 2 hosts involved in a transaction. 


RQ7.40 


A host controller connected to a host with higher HCI version number shall operate according to its own 
version. 



NOTE 2: RQ7.33, RQ7.34, RQ7.35, RQ7.36, RQ7.37 and RQ7.38 are not tested, as they are non-occurrence RQs. 

NOTE 3: In the current version of the present document, there are no previous HCI versions. RQ7.39 is therefore 
not tested in the current version of the present document. 

NOTE 4: Development of test cases for RQ7.40 is FFS. 

5.4.2.4 Loop back gate 

5.4.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 7.1.4 and 4.5. 



RQ4.26 



Registry parameters which are in the range of '00' to 'EF' but which are not allocated in TS 102 622 [1] 
shall not be present in the registry. 



NOTE: Development of test cases for RQ4.26 is FFS . 

5.4.3 Generic gates 

Reference: TS 102 622 [1], clause 7.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.5 HCI procedures 

5.5.1 Pipe management 

5.5.1.1 Pipe creation 

5.5.1 .1 .1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.1, 5.1,6.1.3.1 and 6.1.3.2. 
These conformance requirements must be interpreted in the context of the SDL diagram in clause A.2. 



ETSI 



Release 7 



36 



ETSI TS 102 695-1 V7.0.0 (2010-04) 



RQ6.22 


When the host controller receives an ADMCREATEPIPE command, it shall use the WHITELIST 
defined by the destination host in order to verify that the source host is authorized to create a pipe. 


RQ8.1 


The host controller shall verify that the destination host's administration gate WHITELIST contains 
the host identifier of the source host. If the host identifier of the source host is not part of the 
WHITELIST of the destination host , the host controller shall send 

AMY F PIPF Af^O.F^^ RFMIFD rpt;nnn<5P tn thp csnurrp hn^t anrt <itnn anu fnrthpr nrnrpcicinn nf 

n \ \l 1 1 r 1 r L nUULOO LJ I I ^ I I LJ I CcUUI IOC LU LI 1 C OUUIUC IIUOl a 1 IU O LUU ally 1 U 1 LI ICI L) 1 UL/Coo 1 1 1 u u 

this command. 




If tho cm imo hnct'c hnct irlnntifinr ic nart nf tho WHIXFI IQT nf tho Hoctinatinn hnct tho hnct 

II LI Ic bU U 1 Lc 1 lUOl O 1 IUo L IU tr 1 1 LI 1 1 CI lo \Ja\ I Ul LI Ic VV nl 1 L-LIO 1 U 1 LI IC Utrbll 1 Id LIU 1 1 1 lUb L, LI IC 1 lUOL 

controller shall continue with the procedure. 


RQ8.3 


The host controller assigns an unused pipe identifier. 




Tho hnct nnntrnllor nntifioc tho HoctinQtinn hnct that tho cmimo hnct romioctoH tho (TOQtinn nf 
1 lie MUbL UUIILIUMcl ilUUIltfo Lllc UcoU 1 IcUIUI 1 IIUol III ell lllc oUUlL>c HUbl IcLjUcolcU LI Ic L-lcdUUIl Ul 

PIPE X . 


RQ6.24 


When the host controller sends an ADM_NOTIFY_PIPE_CREATED command, the command 

naramptprQ chall ha R h\/toc Innn 

[Jdl al 1 IC LCI O olldll UG «J UyLCO IUIILJ. 


RQ6.25 


When the host controller sends an ADM_NOTIFY_PIPE_CREATED command as a result of an 

ADM fRFATF PIPF nnmmanrl hoinn ronoi\/nrl f mm a hnct tho cnnrro U|, n in tho rnmmanrl 
rtL/ivi uncn i l_ nrt ouiiniidiiu uci i ilj i cuci vcu iiuiii d i iubi, li ic buuiuc rn|D 1 1 1 li ic l.ui i i i i idi iu 

parameters shall be the H !D of that host. 


ROB 23 


Whpn thp ninp cunnpccfiillv prpptprl thp hn^t pnntrnllpr Qh?i 1 1 c.pnH thp rpenonco ANY OK in 

v v i ici i li ic jji jjc vvcio ouuwoo i u 1 1 y oi cqicu , ii ic iiuoli^ljiiliumci oiidii oc i i\j u ic i coljvj i loc m n i v_/i \ 1 1 1 

response to the ADM_CREATE_PIPE command, with parameters as specified in TS 102 622 [1]. 


RQ8.5 


Thp ho^t mntrnllpr rp^nnnd^ tn ADM CRFATF PIPF that PIPF ha^ hppn rrpatpd 

1 1 1 \j 1 IUOI vUl 1 LI UN w 1 1 UO|JVh/l IU J IU I \ 1 — / 1 V 1 \—J 1 1 1— I \ 1 l_ 1 1 1 l_ 11 1 CI LI II 1 1 1 CIO Uvvl 1 \j 1 uuLUU . 


RQ8.6 


When the host controller wants to create a pipe then the pipe identifier is assigned and only steps 2 
and 3 in figure 6 of TS 102 622 [1] are needed. 


RQ8.7 


When a pipe is created towards the host controller then only steps 1 and 4 in figure 6 of 
TS 102 622 [1] are needed. 


RQ8.8 


If the host controller does not accept the creation of the pipe, it shall respond to 
ADM CREATE PIPE with an appropriate response code. 



NOTE 1: RQ6.22 is contained with RQ8.1 and RQ8.3; it is therefore not explicitly tested within this clause. 

NOTE 2: RQ8.4 and RQ6.25 are not currently tested, as they require access to the interfaces between two hosts and 
the host controller. 

NOTE 3: RQ8.5 is a duplicate of RQ6.23; it is therefore not explicitly tested within this clause. 

NOTE 5: Test cases for RQ8.1, RQ8.2, RQ8.3, RQ8.6, RQ8.7, RQ8.8, RQ6.24 and RQ6.23 is presented in 
TS 102 695-3 [10]. 

5.5.1.2 Pipe deletion 

5.5.1.2.1 Conformance requirements 



Reference: TS 102 622 [1], clauses 8.1.2, 6.1.3.3 and 6.1.3.4. 



RQ8.9 


After receiving a valid ADM DELETE PIPE command from a host, the host controller notifies the 
destination host (with an ADM NOTIFY PIPE DELETED command). 


RQ6.28 


When the host controller sends an ADM_NOTIFY_PIPE_DELETED command, the command 
parameters shall be 1 byte long. 


RQ6.26 


The host that requested the deletion of the pipe can only be the source host or destination host. 


RQ6.27 


When the pipe is successfully deleted, the host controller shall send the response ANY_OK without 
parameters. 


RQ8.10 


When PIPEx connects to a gate at the host controller and the connecting host requests the deletion, 
then only steps 1 and 4 in figure 8 of TS 102 622 [1] are needed. 


RQ8.11 


When PIPEx connects to a gate at the host controller and the host controller requests the deletion, then 
only steps 2 and 3 in figure 8 of TS 102 622 [1] are needed. 



NOTE 1: Further test cases for RQ6.26 are presented in TS 102 695-3 [10]. 

NOTE 2: Development of test cases for RQ8.9, RQ8. 10, RQ8.1 1 and RQ6.28 is FFS. 
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5.5.1 .2.2 Test case 1 : valid pipe deletion from host to host controller 

5.5.1.2.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.1.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 

• A dynamic pipe (PIPE_X) has been created from a gate on the host simulator to a gate on the host controller, 
and is currently open. 



5.5.1 .2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ADM_DELETE_PIPE(PIPE_X) on PIPE1. 




2 


HCUT HS 


Send ANY_OK with no parameters. 


RQ6.27, 
RQ6.26 



5.5.1.3 Clear all Pipes 

5.5.1.3.1 Conformance requirements 

Reference: TS 102 622 [1], clauses 8.1.3, 6.1.3.5 and 6.1.3.6. 



RQ6.29 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command and the data link layer 
specified in TS 102 613 [2] is used, it shall interpret the two bytes in the command parameters as the 
identity reference data, and shall use the identity reference data to initialize the reference data used by 
the host controller to check the UICC host identity. 


RQ6.30 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command, it shall delete all the 
dynamic pipes connected to the requesting host, close all static pipes connected to the requesting host 
and set all registry values related to static pipes connected to the requesting host to their default values. 


RQ6.31 


When ADM_CLEAR_ALL_PIPE is successful the host controller shall respond with an ANY OK without 
parameters. 


RQ6.32 


When the host controller receives a valid ADM_CLEAR_ALL_PIPE command from a requesting host, it 
shall send ADMNOTIFYALLPIPECLEARED to every host with at least one pipe to the requesting 
host. 


RQ6.33 


When the host controller sends an ADM NOTIFY ALL PIPE CLEARED command with the host 
controller as the requesting host, it shall delete all dynamic pipes between the host controller and the 
host and shall close all static pipes between the host and the host controller. 


RQ6.34 


When the host controller sends an ADM NOTIFY ALL PIPE CLEARED command, the command 
parameters shall be one byte long and shall contain the H| D of the requesting host. 



5.5.1.3.2 Test case 1 : identity reference data when TS 102 613 is used 

5.5.1.3.2.1 Test execution 

5.5.1.3.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• SYNC ID needs to match. 
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uircouun 


Ucscnpiiun 




1 


HS HCUT 


Send ADMCLEARALLPIPE with value 

inCMTITV DCCCDCMrC RATA 

IULN III" ntrtntl\Ut UA 1 A. 




d. 


MUU I / no 


OGNQ AN Y Ur\. 




o 


UC -i. UOI IT 

no x ML/U 1 


ConH A MV ODCM PIPE nrt PIPPi 

OGna ANY UrtN rlrt On rlrtl . 




4 


HCUT HS 


Send ANY OK 




5 


HS HCUT 


oGna AUMob I rAriAMb 1 bK(oboolUN_IUhN 1 1 1 Y, \J\ \)d (Jo U4 (Jo 

AC H7 HQ'\ rtn PIPE1 

Ub U/ Uo ) On rlrtl . 




pi 


i i w i 7 no 


^pnrl ANY OK 




7 


User 
HCUT 


Trigger the host controller to deactivate the SWP interface and then 
reactivate the SWP interface. 




8 


HCUT HS 


Deactivate the SWP interface. 




9 


HCUT HS 


Activate the SWP interface. 




10 


HS ^ ^ 
HCUT 


Perform SWP interface activation using IDENTITY_REFERENCE_DATA 
as SYNC ID, and SHDLC link establishment. 




11 


HS HCUT 


Send ANY OPEN PIPEonPIPEL 




12 


HCUT HS 


Send ANY OK 


RQ6.29 



5.5.1 .3.3 Test case 2: reception of ADM CLEAR ALL PIPE - static pipes, dynamic pipes 

to host 

5.5.1.3.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.1.3.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is open. 

• A pipe (PIPE_LOOP_BACK) has been created to the host controller's loop back gate. 



5.5.1 .3.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS^ HCUT 


Send ADM CLEAR ALL PIPE. 




2 


HCUT^ HS 


Send ANY OK. 


RQ6.31 


3 


HCUT HS 


Wait for a reasonable delay for the host controller to send a command on 
PIPE1. 

If host controller sends a command on PIPE1 , perform step 4. 

If host controller doesn't send a command on PIPE1 , perform steps 5 to 8. 




4 




Check that the command sent in step 3 is ANY_OPEN_PIPE (see note). 


RQ6.30 


5 


HS HCUT 


Send ADM CREATE PIPE on PIPE1 , with source and destination Gid = Gid 
of identity management gate. 




6 


HCUT^ HS 


Send response containing an allowed error response code for the command. 




7 


HS HCUT 


Send ANY OPEN PIPEonPIPEL 




8 


HCUT^ HS 


Send ANY OK. 


RQ6.30 


9 


HS^ HCUT 


Send ANY OPEN PIPE on PIPE LOOP BACK. 




10 


HCUT HS 


Send no response or send response containing an allowed error response 
code for the command. 


RQ6.30 


NOTE: The host simulator must respond appropriately to this command, independently of what command has 
been sent. 



5.5.2 Registry access 

Reference: TS 102 622 [1], clause 8.2. 
There are no new conformance requirements for the terminal for the referenced clause. 
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5.5.3 Host and Gate discovery 

Reference: TS 102 622 [1], clause 8.3. 
There are no conformance requirements for the terminal for the referenced clause. 

5.5.4 Session initialization 
5.5.4.1 Conformance requirements 



Reference: TS 102 622 [1], clause 8.4. 



RQ8.12 


In case the lower layer identity check fails, the host controller shall execute only the following commands: 
ANY OPEN PIPE, ADM CLEAR ALL PIPE, ANY GET PARAMETER, and only if these are sent on 
P\PE V 


RQ8.13 


In case the lower layer identity check fails, the host controller shall return ANY E INHIBITED to all 
commands, except for ANY OPEN PIPE, ADM CLEAR ALL PIPE, ANY GET PARAMETER on 
PIPE1. 


RQ8.14 


In case the lower layer identity check fails, the host controller shall ignore all events on all pipes. 


RQ8.15 


In case the lower layer identity check fails, the host controller shall return the default value of the 
SESSIONJDENTITY. However the value of the SESSIONJDENTITY in the registry remains 
unchanged. 


RQ8.16 


The inhibited state shall be terminated after processing a valid ADM CLEAR ALL PIPE command. 


RQ8.17 


In case the lower layer identity check passes, the host controller shall not enter the inhibited state. 



5.5.4.2 Test case 1 : inhibited state 

5.5.4.2.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.4.2.2 Initial conditions 

• The last value of SESSIONJDENTITY in the host controller's registry is not 'FFFFFFFFFFFFFFFF' . 

• A pipe (PIPE_ID_MAN) has previously been created to the host controller's identity management gate. 

• A pipe (PIPE_LOOP_BACK) has previously been created to the host controller's loop back gate. 

• The host simulator is currently powered down. 

• PIPE1 needs to be open 



ETSI 



Release 7 
5.5.4.2.3 



Test procedure 



40 



ETSI TS 102 695-1 V7.0.0 (2010-04) 



step 


Direction 


Description 


KU 


1 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will fail. 




o 


I lc*r\r _\ UP! IT 

USGT -7 ML/U I 


Trigger the host controller to power up and to activate the lower layer. 




O 

o 


MUU I ^ no 


Power up and activate the lower layer. 




A 

4 


UIC _X Uf"M IX 

no ^ MUU I 


C/-in/-l AMV r\DCM ninr niprn 

benO ANY UrtIN rlrt On rlrtU. 




c 

O 


UOI IX UIC 

ML/U I / no 


CnnH AMV C IMUIIDITCR 

bena any t inmidi i tu. 


rivjo. 1 o 





uc _^ ur*! ix 
no ^ MUU I 


bena ANY_bt l_rAnAMt 1 tn(ntU tnnUn) On rlrtU. 




■7 

1 


UPI IX uc 
MOU I ^ Mo 


p nn j AMV C IMUIDITCn 

bena any t inmidi i tu. 


□ An 1 O 

nUo.lo 


Q 
O 


uic _^ uir^i ix 
Mo ~7 ML/U I 


C/-in/-l AMV riDCM DIDC /-in DIDC in MAM 

bena ANY UrtN rlrt On rlrt IU MAN. 




y 


l_j a 1 ix _x UIC 
ML/U 1 ~7 Mo 


C/-in/-J AMV C IMLJiniTCn 

bena any t inmidi itu. 


□ An -J O 

nUo.lo 


1 n 
1 u 


uic ufM ix 
Mo / ML/U 1 


Con/H AMV OCT DADAMCTCD/PATCC 1 ICT\ nn PIPE in yfiM 
bena ANY otl rAnAIVIt 1 tn(oAI tb LlblJOnrlrt IU MAN. 




4 4 
\ \ 


UPI IX uc 
ML/U 1 ^ Mo 


Cr\t->ri AMV C IMUIDITCn 

bena any t inmidi i tu. 


□ An 1 O 


12 


HS^ HCUT 


Conrl AMV ADCM PIPP /-in PIPE 1 PlPlP PAPI^ 

bena ANY UrtN rlrt On rlrt LUUr DAL/I\. 




13 


1 1 (~\ 1 IT X l_IO 

HOUT HS 


Pnn*J A MV | — IMUIDITm 

bend ANY E INHIBITED. 


RQ8.13 


4 A 

1 4 


up \ i i i it 

Hb -7 HOU 1 


P«n^J D\/T PI AflT nATA nnntnininn T\ 4 AO OO O A ' « n 1 OAD D A O 

bend tv 1 Hub IDA 1 A containing 01 02 03 04 on rlrcLuurbAOK. 




4 C 
1 


HOU 1 "7 Mb 


no messages on MrtLUUrBAOrv 


HUB. 14 


16 


i i p \ |i i it 

Hb -7 HOU 1 


p«n^j amv /^ddm nine «n nmc4 

bend ANYUrtNrlrt on rlrtl . 




1 7 


U/" 1 ! IT \ MO 

HOU 1 -r Hb 


bend response = ANYUK. 


D/^O 4 O 


18 


UP \ U/"*l IT 

Hb -7 HOU 1 


P^n^J AMV /~» CT DAD AUCTCD/PCOOmM inCMTITVl «n ninr4 

bend ANY bt I rAHAMt 1 tK(btbblON_IUtN 1 1 1 Y) on rlrtl . 




■i r» 
19 


i_| /~i 1 |T \ UP 

HOU 1 -7 Hb 


bend ANY_OK With parameter value rr rr rr rr rr rr rr rr . 


HU8.15 


20 


HS -7 HCUT 


bend AUM_OKtA l ^Mlrt with source Oid = tt and destination Oid = Oid 




of identity management gate. 




01 


ur*i ix uc 
ML/U 1 ~7 Mo 


n nn H AMV E IMUIPITm 

bena any t inmidi itu. 


nnn 4 o 

nUo.lo 


oo 


uc _^ ur^i ix 
Mo ~7 ML/U 1 


C/-in/-l AMV ^1 ACC PIPCT/Pipr in yAM^ nn PIPCi 

bena ANY_OLUbt_rlrt(rlrt_IU_MAN) On rlrtl. 




oo 
£o 


l_j a | ix _x UC 
ML/U 1 ~7 Mo 


C/-in/-J AMV C IMUIDITCn 

bena any t inmidi itu. 


nnn 4 o 

nUo.lo 


24 


HS HCUT 


Send ADM_DELETE_PIPE(PIPE_ID_MAN) on PIPE1. 




oir 


i_| /~i 1 |T \ UP 

HOU 1 -r Hb 


P«n^J AMV C IMUIDITCn 

bend any t inhibi i tu. 


rn /"i c 4 n 


o^* 


U P \ |P IT 

Hb -> HOU 1 


P«n~l ARAA ni rAD Al i nine _„ ^mD^ 

bend AUM OLtAK ALL rlrtonrlrtl. 




27 


HCUT^ HS 


Send ANY OK. 




28 


l I f\ x i i /—\ i i —j— 

HS -> HCUT 


Send ANY OPEN PIPEonPIPEL 




29 


HCUT^ HS 


Send ANY OK. 




30 


HS -7 HCUT 


Send ANY OPEN PIPE on PIPE0. 




31 


HCUT^ HS 


Send ANY OK. 


RQ8.16 


34 


HS HCUT 


Send ADM SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPE1. 




35 


HCUT^ HS 


Send ANY OK. 


RQ8.16 


36 


HS -7 HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source and destination Gid = Gid 
of identity management gate. 




37 


HCUT HS 


Send ANY OK (parameters are not checked); designated the created pipe 
PIPE ID MAN. 


RQ8.16 


NOTE 


After step 3 if the host controller sends comments the host simulator shall respond according to its 




initial state. 







5.5.4.3 Test case 2: inhibited state, followed by subsequent successful identity check 

5.5.4.3.1 Test execution 

There are no test case-specific parameters for this test case. 

5.5.4.3.2 Initial conditions 

• The last value of SESSION_lDENTITY in the host controller's registry is not 'FFFFFFFFFFFFFFFF. 

• The host simulator is currently powered down. 
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step 


Direction 


Description 


rfU 


1 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will fail. 




2. 


1 Inni- X 1 1 1 IT 

User -> HGU I 


Trigger the host controller to power up and to activate the lower layer. 




3 


LI/" 1 ! IT X LJO 

HGU 1 -7 Ho 


Power up and activate the lower layer. 




4 


LJO X I | I it 

Hb -> HGU 1 


bend ANY UrtN rlrt on rlrtu. 







l_| | |T _X LJO 

HGU 1 "7 Mb 


0^i-«^J A M\/ C IMUIDITLTn 

bena any_c_inhibi i bu. 




r» 



i x i i r* 1 IT 

User -> HOU I 


Trigger the host simulator to be powered down. 




7 


HCUT^ HS 


Power down the host simulator. 




8 


HS 


Change the host configuration such that the lower layer identity check 
mechanism will pass. 




9 


ii x it /"\ i i ~r 

User -> HCUT 


Trigger the host simulator to be powered up. 




10 


1 1 /"^ 1 IT X 1 1 

HCUT -> HS 


Power up the host simulator. 




11 


HS^ HCUT 


Send ANY_OPEN_PIPE on PIPE1 . 




12 


HCUT^ HS 


Send response (contents are not checked). 




13 


HS^ HCUT 


Send ANY_GET_PARAMETER(SESSION_IDENTITY) on PIPE1. 




14 


HCUT HS 


Send ANY_OK with parameter value containing the same value as previously 
set (see initial conditions). 


RQ8.15 


15 


HS -» HCUT 


Send ADM SET PARAMETER(SESSION IDENTITY, '01 02 03 04 05 06 07 
08') on PIPE1. 




16 


HCUT^ HS 


Send ANY OK. 


RQ8.17 


NOTE: After step 3 if the host controller sends comments the host simulator shall respond according to its 
initial state. 



5.5.5 Loop back testing 

5.5.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 8.5. 



RQ8.18 


The host controller shall accept the creation of a pipe to its loop back gate from any gate in another host. 


RQ8.19 


When the host controller receives the event EVT_POST_DATA on a pipe connected to its loop back 
gate, it shall send back the event EVT POST DATA with same data as received in the received 
EVT POST DATA. 


RQ8.20 


The loopback gate shall support at least all messages with size up to 250 bytes. 



5.5.5.2 Test case 1 : processing of EVT_POST_DATA 

5.5.5.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• EVT_POST_DATA data sizes of: 250 bytes. 

5.5.5.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A pipe (PIPE_LOOP_BACK) has been created to the host controller's loop back gate using source G ID . 11', 
and is open. 
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5.5.5.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send EVTPOSTDATA on PIPE_LOOP_BACK containing data of the 
specified size. 




2 


HCUT HS 


Send EVT POST DATA on PIPE_LOOP_BACK containing the same data 
as in step 1 . 


RQ8.19, 
RQ8.20 



5.6 Contactless card emulation 

5.6.1 Overview 

5.6.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.1. 



RQ9.1 


The CLF shall handle the RF communication layers to the external contactless reader. 


RQ9.2 


The host controller has one card RF gate for each RF technology it supports. 


RQ9.3 


For the contactless platform for card emulation mode the pipes to card RF gates shall be created, 
opened, closed and deleted by the host. 


RQ9.4 


The RF technology of a card RF gate is active when there is an open pipe connected to it. 


RQ9.5 


The host controller shall activate one or more RF technologies as requested by the host to the external 
reader. 



NOTE: Development of test cases for RQ9.3 is FFS. 

5.6.1.2 Test case 1 : RF gate of type A 

5.6.1 .2.1 Test execution 

There is no test case specific parameters for this test case. 

5.6.1.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered on. 



5.6.1 .2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send ADM_CREATE_PIPE on PIPE1 , with source Gid = '23' and 
destination Gid = Gid of type A card RF gate; designate the created pipe 
PIPEa. 




2 


HCUT HS 


Send ANY OK 


RQ9.2, 


3 


HS -» HCUT 


Send ANY OPEN PIPE on PIPEa 




4 


HCUT HS 


Send ANY OK 




5 


HS HCUT 


Send ANY _GET PARAMETER (MODE) on PIPEa 




6 


HCUT^ HS 


Send ANY OK with a parameter value of 'FF' 




7 


HS -» HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa 




I 8 


HCUT HS 


Send ANY OK 




9 


PCD HCUT 
HCUT^ PCD 


Perform anti-collision as described in ISO/IEC 14443-3 [6] Type A. 


RQ9.1, 
RQ9.4, 
RQ9.5 
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5.6.1.3 Test case 2: RF gate of type B 

5.6.1 .3.1 Test execution 

There is no test case specific parameters for this test case. 

5.6.1.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• PIPE1 is currently open. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered on. 



5.6.1 .2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS -» HCUT 


Send A D M_C R E ATE P I P E on PIPE1 , with source Gid = '21 ' and 
destination Gid = Gid of type B card RF gate; designate the created pipe 
PIPEa. 




2 


HCUT HS 


Send ANYOK. 


RQ9.2, 


3 


HS -» HCUT 


Send ANY OPEN PIPE on PIPEa. 




4 


HCUT HS 


Send ANY OK. 




5 


HS -» HCUT 


Send ANY _GET PARAMETER (MODE) on PIPEa. 




6 


HCUT^ HS 


Send ANY OK with a parameter value of 'FF'. 




7 


HS HCUT 


Send ANY SET PARAMETER (MODE, '02') on PIPEa. 




I 8 


HCUT HS 


Send ANY OK. 




9 


PCD HCUT 
HCUT^ PCD 


Perform anti-collision as described in ISO/IEC 14443-3 [6] Type B.. 


RQ9.1, 
RQ9.4, 
RQ9.5 



5.6.2 Void 

Reference: TS 102 622 [1], clause 9.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3 Gates 

5.6.3.1 Void 

Reference: TS 102 622 [1], clause 9.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.2 Identity management gate 
5.6.3.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 9.3.2. 



RQ9.6 


If low power mode is supported, the parameter LOW_POWER_SUPPORT of identity management gate 
shall be '01'. 


RQ9.7 


If low power mode is not supported, the parameter LOW POWER SUPPORT of identity management 
gate shall be '00'. 


RQ9.8 


The host controller shall apply the access condition of RO to LOW_POWER_SUPPORT. 
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5.6.3.3 Card RF gates 

5.6.3.3.1 Overview 

Reference: TS 102 622 [1], clause 9.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.2 Commands 

5.6.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.3 Events and subclauses 

5.6.3.3.3.1 Events 

5.6.3.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.3. 
|RQ9.10 |The Card RF gates shall support the EVTSENDDATA event. | 

NOTE: RQ1 is tested in clause 5.6.4. 

5.6.3.3.3.2 EVTSENDDATA 

Reference: TS 102 622 [1], clause 9.3.3.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.3.4 Registry and subclauses 

5.6.3.3.4.1 Registry 

5.6.3.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4. 
|RQ9.11 |AII registries shall be persistent. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.3.4.2 RF technology type A 
5.6.3.3.4.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 9.3.3.4.1. 



RQ9.12 


The CLF shall only accept values of MODE of 'FF' and '02' 


RQ9.13 


The CLF shall set a default value for MODE of 'FF'. 


RQ9.14 


The CLF shall apply the access condition of RW for MODE. 


RQ9.15 


The CLF shall use a default value for UID REG of length zero bytes 


RQ9.16 


If Length of UID_REG equals then the CLF generates a single size UID with uidO ='08'and uid1 to uid3 
as random numbers. 
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RQ9.1 7 


The random numbers shall be generate only on state transitions POWER_OFF to IDLE state (state 
definitions according to ISO/IEC 14443-3 [6]) The CLF shall interpret the absence of an RF-field as 

DHU/CD rice ot^to 
rUVvtn-Urr Siaie. 


rSLjy.1 o 


lfl/-»t-i/-4tl-i/-»/-uiolc*/1 7 nr 1 n ihnn thn A| C nholl i ion I lin DCP op I lin 

it Lengm equals 4, / or iu men me L/Lr snan use uiu_ritLj as uiu. 


Dr*lQ ^ Q 

Hijy.i y 


i ne L/Lr snan appiy me access conamon ot vvu Tor uiuntLi. 


ppiq on 
riUy.^U 


i ne olt snan sei a aerauit vaiue Tor s>ai\ ot uu . 


mjy.^1 


The CLF shall apply the access condition of RW for SAK 


□HQ OO 


Tkn C c*k-»oll o /"-l/-»foi il+ woli f/-»K ATAA /-if 'flflflfl 1 

1 ne L/Lr snan sei a oeiauii vaiue Tor a i ua ot uuuu . 


nr\n no 

riUy.^o 


The CLF shall apply the access condition of RW for ATQA. 


mjy.^4 


Tho P eholl cat n /Hafmilt woliia fr\r APPI IPATIPlM RATA r\f 'NM A" 

1 ne OLr snan seT a oerauiT vaiue Tor ArrLiL/A i iuin ua i a ot in n =u . 


DflQ OC 

riuy.^o 


T[-i/-i P cl-ioll r> 1-1 1-» 1 \ / th/-i o/^/^/-ic*o /^/-in/-liti/-in /-if P\A/ f/-vt- APPI lAATiriM PlATA 

1 ne L/Lr snan appiy ine access conoiTion ot nvv Tor Ar r lioa i iuin ua i a. 


RQ9.26 


The CLF shall set a default value for FWI, SFGI of 'EE'. 


nUy.i:/ 


The CLF shall apply the access condition of RW for FWI, SFGI. 


RQ9.28 


The CLF shall require the support of CID if CID_SUPPORT ='01'. 


RQ9.29 


The CLF controller shall not require the support of CID if CID_SUPPORT = 00 . 


RQ9.30 


The CLF shall set a default value for CID SUPPORT of 00 . 


RQ9.31 


The CLF shall apply the access condition of RW for CID_SUPPORT. 


RQ9.32 


If the CLF contains a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant protocol 
support then the value of CLT_SUPPORT shall be '01'. 


RQ9.33 


If the CLF does not contain a tunneling mode capability for type A ISO/IEC 14443-4 [7] non compliant 
protocol support then the value ot ol i_bUrrUK I snail De 00. 


nnn Qyl 
HUy.j4 


TU n z -1 ! p ol-»oll o^^lw t^ir\ ^^/-»/-l!ti r\ /-i r\f P/^ +a 1 T Ol IDDADT 

i ne L/Lr snan appiy tne access condition or uu to l-l i ourrun i 


RQ9.35 


The host controller shall support DATARATE_MAX which codes maximum divisor supported with coding 
as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum divisor supported in direction PCD to PICO 

• Byte 3 defines the limitation to support different divisors for each direction. 


RQ9.36 


The CLF shall set a default value for DATARATE_MAX of 030300 . 


RQ9.37 


The CLF shall apply the access condition of RW for DATARATE MAX. 


RQ9.38 


The CLF shall use the minimum of the value indicated in the registry and the maximum divisor 
implemented in the CLF as the maximum support divisor indicated in TA (1) as defined in ISO/IEC 
14443-4 [7]. 


RQ9.39 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE 1: Test cases for RQ9.12, RQ9.13 and RQ9.14 are presented in TS 102 695-3 [10]. 

NOTE 2: Further test cases for RQ9.18, RQ9.21, RQ9.23, RQ9.26 and RQ9.27 are presented in TS 102 695-3 [10]. 
NOTE 3: Development of test cases for RQ 9.39 is FFS. 

NOTE 4: Development of test cases for RQ 9.32, RQ 9.33 and RQ 9.34 is FFS. 
5.6.3.3.4.2.2 Test case 1 : UID REG - default 

5.6.3.3.4.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• This test case is assumed that only one HCUT (PICC) is presented in the RF field. 

5.6.3.3.4.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ID = ' 23' to the card RF gate of type A. 

• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type A. 

• MODE is set to '02'. 
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5.6.3.3.4.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


H 
1 


user -7 muu i 


The terminal is placed in PCD field. 




o 

d. 


D^R -X l_lf~M IX 


i ransitions Trom ruvvcri_urr to iule state. 




3 


rL/L) -7 HOU 1 


Send REQA. 




4 


HCUT -*PCD 


Send ATQA and enter the READY state. 







rUU-7nUU 1 


Send AC command. 




D 




Send the complete UID, with UID0 = '08', UID1-UID3 randomly generated 
by the CLF. 


KUy.l 0, 
nUy.l D, 

□no 1 7 


7 


ppn -A WPI IT 


ntJlUill IU UIc ILJLC bldlfc? Uy bfcJllUllly nCUn IWIOU. 




o 
o 


upi it _x ppn 

nuU 1 ^7 ruU 


QonH ATPiA anrl ontor tho RPAnV ctpto 
Otfl IU rt I dl IU cl llcl 11 1 c n rZM U I bid It?. 






ppn WPI IT 


OcllU ML/ OUIIIIIIdMu. 




10 


HCUT PCD 


Send UID as it given in step 6. 


RQ9.16, 
□no 1 7 


H H 
I I 


ppn -a mpi it 


Cnnrl CC| PPT p>p\ m m onH \A/ith roroiv/oH 1 lin 
OfcJilU oCLCU 1 OUlIlllldMU Willi IcUclVcU UIL/. 




I 


mpi it -a ppn 


OtfilU OMr\ ^UIU lb OUIMpiclc^. 




I o 


ppn -a mpi it 

r^U ✓ nuu 1 


O /- . t-\/-J |_| [ TA p>/~i m m onrl tr» ontar tho 1— 1 A 1 T oto to 
OfcfilU rlL 1 M OUIillIldMU IU fciMlfcil Lllc rlML 1 bld.lt!. 




1 A 

I *f 


ppn -a mpi it 


QonH Wl IPA 




I 


mpi it -a ppn 


QonH ATPiA 




I D 


ppn -A MPI IT 
ruu ✓ nuu 1 


Onnrl QPI PPT p>p\ m m onrl \A/ith r r\r*r\ i \ i r\r\ \ \\V\ cton A 
OfcJNU OCLCL/ 1 OUlIlllldllU Willi IfcfOfcflvfcfU UIU bLfcip D. 




17 


HCUT PCD 


Send SAK (UID is complete). 


RQ9.16, 
RQ9.17 


I o 


1 |opr -A HPI IT 

UoCI 7 1 1 U 1 


Tho torminal ic ro mn\/oH from tho PPR fiolH 
lllc; LtfiiiiMicii lo itJiiiuvtJU iiuiii ulc; rou iiciu. 




19 


User -» HCUT 


The terminal is placed in PCD field. 




20 


PCD HCUT 


Transitions from POWER OFF to IDLE state. 




21 


PCD HCUT 


Send REQA. 




22 


HCUT-* PCD 


Send ATQA and enter the READY state. 




23 


PCD HCUT 


Send AC command. 




24 


HCUT PCD 


Send the complete UID, with UID0 = '08', UID1-UID3 randomly generated 
by the CLF. 


RQ9.15, 
RQ9.16, 
RQ9.17 



5.6.3.3.4.2.3 Test case 2: SAK 

5.6.3.3.4.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• This test case is assumed that only one HCUT (PICC) is presented in the RF field: 

Single UID of length 4. 

5.6.3.3.4.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ID = '23' to the card RF gate of type A. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered off. 

• MODE is set to '02'. 
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5.6.3.3.4.2.3.3 Test procedure 



oiep 




Ucscnpiiun 


□ n 

PlVjf 


H 
\ 


UIC _^ ur*! IT 
no ^ MUU I 


oGnQ AN Y bt 1 r AnAIVIt 1 tn (A 1 \JR) On rlrta. 




2 


HCUT HS 


Send ANYOK with value '0000'. 




o 
o 


no ✓ nuu 1 


QonH AMV rJFT PARAMETER fQAPO nn PIPFa 
ocMU MIN T 1 rnnnlvIC 1 Cn ^oMrxJ UN rlrCd. 




4 


HCUT HS 


Send ANY OK with parameter '00'. 


ROQ on 
RQ9.21 


5 


User -» HCUT 


The terminal is placed in PCD field. 




6 


PCD HCUT 


Transitions from POWER_OFF to IDLE state. 




7 


PCD HCUT 


Send REQA. 




8 


HCUT -> PCD 


Send ATQA and enter READY state. 




9 


PCD HCUT 


Send AC command. 




10 


HCUT PCD 


Send UID. 




11 


PCD HCUT 


Send SELECT command with received UID. 




12 


HCUT -> PCD 


Send SAK (UID is complete) with the default value. 


RQ9.21 



5.6.3.3.4.2.4 Test case 3: ATS - default parameters 

5.6.3.3.4.2.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• ATS with default value for all parameters. 

5.6.3.3.4.2.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ro = '23' to the card RF gate of type A. 

• ISO/IEC 14443-3 [6] Type A is in ACTIVE state. 

• SAK is set to '20'. 



5.6.3.3.4.2.4.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


PCD HCUT 


Send RATS. 




2 


HCUT PCD 


Send ATS. 


RQ9.24, 
RQ9.26, 
RQ9.30, 
RQ9.32, 
RQ9.33, 
RQ9.36 



5.6.3.3.4.2.5 Test case 4: APPLICATION DATA 

5.6.3.3.4.2.5.1 Test execution 

Run this TC for the following parameters: 

• CIDa = 01. 

• ISO/IEC 7816-4 [8] historical bytes (Tl - Tk) is defined as: 

Category indicator: '80'. 

Card service data: '31', 'E0'. 

Card capabilities: '73', '66', '21' , '15'. 
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5.6.3.3.4.2.5.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ID = '23' to the card RF gate of type A. 

• ISO/IEC 14443-3 [6] Type A is in ACTIVE state. 

• SAK is set to '20'. 



5.6.3.3.4.2.5.3 Test procedure 



Step 


Direction 


Description 


RQ 


[ 1 


HS HCUT 


Send ANY SET PARAMETER (CID SUPPORT, 'CID') on PIPEa 




2 


HCUT HS 


Send ANY OK 


RQ9.31 


3 


HS -» HCUT 


Send ANY _GET PARAMETER (CID_SUPPORT) on PIPEa 




4 


HCUT HS 


Send ANY OK with value given in step 1 


RQ9.31 


1 


HS HCUT 


Send ANY SET PARAMETER (APPLICATION DATA, T1 -Tk) on PIPEa 




2 


HCUT HS 


Send ANY OK 


RQ9.25 


3 


HS HCUT 


Send ANY _GET PARAMETER (APPLICATIONDATA) on PIPEa 




4 


HCUT HS 


Send ANY_OK with value (T1 -Tk) given in stepl 


RQ9.25 


5 


PCD HCUT 


Send RATS 










RQ9.25 


6 


HCUT PCD 


Send ATS with historical bytes (APPLICATION DATA )as defined in stepl 


RQ9.28, 
RQ9.29 



5.6.3.3.4.2.6 Test case 5: DATARATEMAX 

5.6.3.3.4.2.6.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• DATARATE_MAX = '000001'. 

• DATARATE_MAX = '030300'. 

5.6.3.3.4.2.6.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gi D = ' 23' to the card RF gate of type A. 

• ISO/IEC 14443-3 [6] Type A is in ACTIVE state. 

• SAK is set to '20'. 



5.6.3.3.4.2.6.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


HS HCUT 


Send ANY _GET PARAMETER (DATARATE_MAX) on PIPEa 




2 


HCUT HS 


Send ANYOK with default value. 


RQ9.35, 
RQ9.36, 
RQ9.37 


3 


HS HCUT 


Send ANY _SET PARAMETER (DATARATE_MAX, 'Bytel Byte2 Byte3') 
on PIPEa 




4 


HCUT HS 


Send ANY OK 


RQ9.35, 
RQ9.37 


5 


PCD HCUT 


Send RATS 




6 


HCUT^ PCD 


Send ATS with TA(1) value compliant with DATARATE MAX 


RQ9.38 
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5.6.3.3.4.3 RF technology type B 

5.6.3.3.4.3.1 Conformance requirements 



Reference: TS 102 622 [1], clause 9.3.3.4.2. 



RQ9.40 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 


RQ9.41 


The CLF shall only accept values of MODE of 'FF' and '02'. 


RQ9.42 


The CLF shall set a default value for MODE of 'FF'. 


RQ9.43 


The CLF shall apply the access condition of RW for MODE. 


RQ9.44 


The CLF shall only accept values of PUPI of length or 4 bytes. 


RQ9.45 


If N=0 then the CLF shall generate the PUPI as dynamically generated number. 


RQ9.46 


The PUPI shall only be generated by a state transition from the POWER-OFF to the IDLE state(state 
definitions according to ISO/IEC 14443-3 [6]). 


RQ9.47 


The CLF shall interpret the absence of an RF-field as POWER-OFF state. 


RQ9.48 


If N is not equal to 0, the CLF shall use the PUPI_REG as PUPI. 


RQ9.49 


The CLF shall apply the access condition of WO for PUPI_REG. 


RQ9.50 


The CLF shall use the AFI registry parameter as AFI according to ISO/IEC 14443-3 [6]. 


RQ9.51 


The CLF shall set a default value for AFI of '00'. 


RQ9.52 


The CLF shall apply the access condition of RW to AFI. 


RQ9.53 


The CLF shall set a default value for ATQB of '00 00 00 E4'. 


RQ9.54 


The CLF shall only accept values of ATQB of length 4 bytes. 


RQ9.55 


The CLF shall set additional data for ATQB as defined in the registry Table 31 of TS 102 622 [1]. 


RQ9.56 


The CLF shall apply the access condition of RW to ATQB. 


RQ9.57 


The CLF shall set higher layer response in answer to ATTRIB command as defined registry. 


RQ9.58 


The CLF shall set a default value for HIGHER LAYER RESPONSE of 'N2=0'. 


RQ9.59 


The CLF shall apply the access condition of RW for HIGHER LAYER RESPONSE. 


RQ9.60 


The host controller shall support DATARATE_MAX which codes maximum bit rates supported with 
coding as defined in TS 102 622 [1] where: 

• Byte 1 defines the maximum bit rates supported in direction PCD to PICO 

• Byte 3 defines the limitation of having the bit rate in both direction. 


RQ9.61 


The CLF shall set a default value for DATARATE MAX of '030300'. 


RQ9.62 


The CLF shall apply the access condition of RW for DATARATE MAX. 


RQ9.63 


The CLF shall set a default value for ATQB of length 0. 


RQ9.64 


The CLF shall use the minimum of the value indicated in the registry and the maximum bit rate supported 
implemented in the CLF as the maximum bit rate indicated in the first byte of the protocol information as 
defined in ISO/IEC 14443-3 [6]. 



NOTE1 : Development of test cases for RQ9.40 and RQ9.64 is FFS. 

NOTE 2: Further test cases for RQ9.41, RQ9.42 and RQ9.43 are presented in TS 102 695-3 [10]. 
5.6.3.3.4.2.2 Test case 1 : PUPI_REG - default 

5.6.3.3.4.2.2.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• default PUPI_REG parameter. 

• REQB with AFI = 00 and PARAM = 00, so all PICCs shall process this REQB/WUPB. 

5. 6.3.3.4.2.2.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ID = '21' to the card RF gate of type B. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered off. 

• MODE is set to '02'. 
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5.6.3.3.4.2.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


H 
1 


i_io _^ i_i i it 
Mb -7 MUU 1 


Qnni-l A M V rz~T DADAMCTCD / □ i ini nrp\ _„ ninr„ 

bena ANY _bb 1 _rAKAIVIb 1 bn (rUrl_Kb(j) on rlrba 




2 


HCUT HS 


Send response containing an allowed error response code for the 
command. 




q 
O 




i ne terminal is piaceo in rou neia 




A 

4 




i ransiiions Trom ruvvtri urr io iulc siaie 




c 

O 


pr*n uipi it 


oena ntuo 




6 


HCUT PCD 


Send ATQB with PUPI dynamically generated number. 


DAQ A £ 

RQ9.46, 

RPiQ A7 


7 


ppn -A WPI IT 


rituurri lu me \U\-C bidit? uy benuiiiy ricv^D iwioe 




o 
o 


up| it _x ppn 

nuU 1 ^7 ruU 


CionH ATPlR vwith PI IPI valiio ni\/on in ctonR 
otfi iu rtiv^D win i run vaiuo yivcii hi otcpu 




Q 


ppn WPI IT 


QonH ATTRIR roni loct 
OcIlU M 1 1 r\ID reL|ueoi. 




1 n 


upi it -a ppn 


QonH ATTRIR R rocnnnco 




H H 
I I 


ppn wpi it 


Q Qnr J |_|| TR tn ontor tho WAI T ctato 

oenu nL i d lu tJiutii inti nML i bicue. 




12 


PCD HCUT 


Send WUPB 




13 


HCUT PCD 


Send ATQB with PUPI value given in step6. 


RQ9.47 


14 


User HCUT 


The terminal is removed from the PCD field 




15 


User -» HCUT 


The terminal is placed in PCD field 




16 


PCD HCUT 


Transitions from POWER OFF to IDLE state. 




17 


PCD HCUT 


Send REQB 










RQ9.45, 


18 


HCUT PCD 


Send ATQB with PUPI dynamically generated number. 


RQ9.46, 
RQ9.47 



5.6.3.3.4.2.3 Test case 2: ATQB - verify the different parameter 

5.6.3.3.4.2.3.1 Test execution 

The test procedure shall be executed once for each of following parameters: 

• PUPIa = '01 02 03 04', AFIa = '40' and ATQB is coded for the following values: 

Protocol information is coded PROTO_INFO = '70'. 

Numbers of Applications byte is coded for, NUMBER_APLI = 0-15. 

• PUPIa = '12 34 56 78', AFIa = '20' and ATQB is coded for the following values: 

Protocol information is coded PROTOJNFO = '85'. 

Numbers of Applications byte is coded for, NUMBER_APLI = 0-15. 

5.6.3.3.4.2.3.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source G ID = '21' to the card RF gate of type B. 

• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type B. 

• MODE is set to '02'. 
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5.6.3.3.4.2.3.3 Test procedure 



Step 


Direction 


Description 


RQ 


H 
1 


i_io _^ i_i i it 
Mb -7 MUU 1 


0^i-«^J A M\/ ACT D A D A l\ flCXC D /□! IDI DC/~M DIDCo 

bend ANY Jjb 1 rAMAMb 1 bn (rUrl_Mblj) on rlrba. 




2 


HCUT HS 


Send response containing an allowed error response code for the 
command. 


KU9.4y 


o 
o 


1_IC _X l_l f~- 1 IX 

Mb "7 MUU 1 


G^m-l AMV OCX DADAULTLD /Dl IDI DLP 'Dl IDIo'\ DIDCn 

bena ANY _bb I rAMAMb 1 bn (rUrl Mblj, rUrla ) On rlrba. 




4 


HCUT HS 


Send ANYOK. 


D/"\n A A 

HUy.44, 

RQ9.49 


5 


HS HCUT 


Send ANY _GET PARAMETER (AFI) on PIPEa. 




6 


HCUT HS 


Send ANY OK with value '00'. 


RQ9.51, 
RQ9.52 


7 


1 1 /™i x ii /~i i i T" 

HS -7 HCUT 


|— \ ■ « fc |\ g f~ \ 1 1- I—. « l—i A ■ a | 1-| — | — V / A 1 — | 1 A i — n\ nini — 

Send ANY SET PARAMETER (AFI, AFI ) on PIPEa. 




8 


HCUT HS 


Send ANY OK. 


RQ9.50, 
RQ9.52 


9 


HS HCUT 


Send ANY _GET PARAMETER (ATQB) on PIPEa. 




10 


HCUT -> HS 


Send ANY_OK with value 00 00 00 E4 . 


RQ9.53, 
RQ9.54 
RQ9.55, 
RQ9.56, 
RQ9.63 


11 


HS -» HCUT 


f\ 1 A h l \ / /~i 1 1~ 1 — \ A 1 — * AHA 1 l~l — ft / A "T"/*~\ |— 1 1 |-\ 1—1 /~~\ ~T~ / — \ 1 h 1 I — v*~v K II 1 f, ft n i — i — \ A r~i 1 II 

Send ANY SET PARAMETER (ATQB, PROTOJNFO, NUMBER APLI 
) on PIPEa. 






LJf"*! IX _X l_IC 

MOU 1 -7 Mb 


bena anyuk.. 


RQ9.54 

Muy.oo, 

RQ9 56 


13 


HS HCUT 


Send ANY _GET PARAMETER (ATQB) on PIPEa. 




14 


HCUT HS 


Send ANY_OK with value 'PROTOJNFO, NUMBER_APLI'. 


RQ9.54 
RQ9.55, 
RQ9.56 


15 


User -» HCUT 


The terminal is placed in PCD field. 




1 6 


PCD -7 HCUT 


Transitions from POWEROFF to IDLE state. 




17 


PCD HCUT 


Send REQB to enter the READY state. 










RQ9.54, 


18 


HCUT PCD 


Send ATQB with parameters as defined for: 

• PUPI same value as given in step3. 

• AFI same value as given in step7. 

• ATQB other parameters with the same values as given in stepl 1 . 


RQ9.55, 
RQ9.56, 
RQ9.47, 
RQ9.48, 
RQ9.50 



5.6.3.3.4.3.4 Test case 3: HIGHER LAYER RESPONSE 

5.6.3.3.4.3.4.1 Test execution 

The test procedure shall be executed once for each of following parameters: 



• HIGHER_LAYER is coded for the following values. 



HIGHER LAYER RESPONSE 
registry value 


Higher layer - INF to be included 
in ATTRIB command sent by 
PCD 


Expected Higher layer Response to be 
included in answer to ATTRIB command 
sent by CLF 


'01 02 03 04 05 06 07 08 09 OA' 


'11 12 13 14 15' 


'01 02 03 04 05 06 07 08 09 OA' 



• D AT AR ATE_M AXa = ' 00000 1 ' 

5.6.3.3.4.3.4.2 Initial conditions 

• The HCI interface is idle; i.e. no further communication is expected. 

• A PIPEa is created and opened by the host with source Gi D = '21' to the card RF gate of type B. 

• The Proximity Coupling Device (PCD) supports ISO/IEC 14443-3 [6] Type B. 
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Step 


Direction 


Description 


|->/"\ 

RQ 


1 


HS -» HCUT 


Send ANY _GET PARAMETER (DATARATEMAX) on PIPEa. 




2 


HCUT HS 


Send ANYOK with value '030300'. 


RQ9.60, 
RQ9.61, 
RQ9.62 


3 


HS HCUT 


Send ANY _SET PARAMETER (DATARATE MAX, 'DATARATE MAXa') 
on PIPEa. 




4 


HCUT HS 


Send ANY OK. 


RQ9.60, 
RQ9.62 


5 


HS -» HCUT 


Send ANY _GET PARAMETER (HIGHERLAYERRESPONSE) on 
PIPEa. 




6 


HCUT HS 


Send ANY_OK with parameter value of length zero. 


RQ9.58, 
RQ9.59 


7 


HS HCUT 


c n »~i a m\/ o — r n a n a i\ *rTr n /Lii/^Lii^n I A\/i^n n I — on mo — 

Send ANY SET PARAMETER (HIGHER LAYER RESPONSE, 
nlunbriLAYbria ) On rlrba. 




8 


HCUT HS 


Send ANY OK. 


RQ9.58, 
Kuy.oy 


9 


HS HCUT 


benu ANY Ijbl rAriAMb 1 Eri (MHjnEK LAYbK KbbrUNbb) on 
PIPEa. 




10 


HCUT HS 


Send ANY OK with value ' HIGHERLAYERa' as given in step3. 


□no 
RQ9.59 


11 


User ^ HCUT 


The terminal is placed in PCD field. 




12 


PCD HCUT 


Send REQB. 




13 


HCUT PCD 


Send ATQB. 


RQ9.60 
RQ9.61 


14 


PCD HCUT 


Send ATTRIB. 




15 


HCUT PCD 


Send Answer to ATTRIB. 


RQ9.57, 
RQ9.60 



5.6.3.3.4.4 RF technology type B' 

5.6.3.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.3.4.3. 

NOTE: Defining conformance requirements is out of scope of the present document. 

5.6.3.3.4.5 RF technology Type F (IS01 8092 21 2 kbps/424 kbps card emulation only) 
5.6.3.3.4.5.1 Conformance requirements 



Reference: TS 102 622 [1], clause 9.3.3.4.4. 



RQ9.65 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 


RQ9.66 


The CLF shall only accept values of MODE of 'FF' and '02'. 


RQ9.67 


The CLF shall set a default value for MODE of 'FF. 


RQ9.68 


The CLF shall apply the access condition of RW for MODE. 


RQ9.69 


The CLF shall support the capabilities indicated in the SPEED CAP parameter as specified in 
TS 102 622 [1]. 


RQ9.70 


The CLF shall apply the access condition of RO to SPEED_CAP. 


RQ9.71 


The CLF shall contain a tunneling mode capability for type F card emulation anti-collision support if 
CLT_SUPPORT='01\ 


RQ9.72 


The CLF shall not contain a tunneling mode capability for type F card emulation anti-collision support if 
CLT SUPPORT ='00'. 


RQ9.73 


The CLF shall apply the access condition of RO to CLT SUPPORT. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.3.4 Card application gates 

5.6.3.4.1 Overview 

Reference: TS 102 622 [1], clause 9.3.4.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.4.2 Commands 

5.6.3.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.3.4.3 Events and subclauses 

5.6.3.4.3.1 Events 

5.6.3.4.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3. 
|RQ9.74 | When sending to a card application gate, the CLF shall respect the values and events as listed. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.4.3.2 EVTFIELDON 
5.6.3.4.3.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 9.3.4.3.1. 



RQ9.75 


When EVT FIELD ON is sent by the host controller, it shall be sent within 2 ms after the detection of an 
RF field. 


RQ9.76 


In case of an underlying data link layer according to TS 102 613 [2], if SWP is in DEACTIVATED state, 
the CLF shall activate the interface instead of sending the EVT FIELD ON. 


RQ9.77 


When the host controller sends EVT_FIELD_ON, it shall not contain parameters. 



NOTE: Development of test cases for above listed RQs is FFS. 
5.6.3.4.3.3 EVTCARDDEACTIVATED 

5.6.3.4.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.2. 
|RQ9.78 | When the host controller sends EVT CARD DEACTIVATED, it shall not contain parameters^ 

NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.3.4.3.4 EVTCARDACTIVATED 

5.6.3.4.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.3. 
|RQ9.79 | When the host controller sends EVT CARD ACTIVATED, it shall not contain parameters. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.4.3.5 EVTFIELDOFF 

5.6.3.4.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.4. 
|RQ9.80 |When the host controller sends EVT_FIELD_OFF, it shall not contain parameters. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.4.3.6 EVTSENDDATA 

5.6.3.4.3.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.3.5. 
|RQ9.81 I On sending E VT S E N D DATA the CLF shall set the last parameter byte as RF error indicator. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.6.3.4.4 Registry 

5.6.3.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.3.4.4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.4 Procedures 

5.6.4.1 Use of contactless card application 
5.6.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.1. 

NOTE: These requirements apply for usage of ISO/IEC 14443-4 [7] . 
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RQ9.82 


In full power mode, when the CLF detects a RF field, the card RF gate shall send the event 
EVT_FIELD_ON to the card application gate unless otherwise as specified in clause 9.3.4.3.1 . 


RQ9.83 


When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gid. 


RQ9.84 


When the CLF detects a RF field, and after sending EVT_FIELD_ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/IEC 14443-3 [6] using the parameters from the 
appropriate card RF gate registry for the present RF technology 


RQ9.85 


If The card RF gate sends EVT CARD ACTIVATED to the card application gate, it shall send it at the 
end of the activation sequence as defined ISO/IEC 14443-4 [7]. 


RQ9.86 


The card RF gate shall forward the C-APDUs from the external contactless reader to the card application 
gate using the EVT SEND DATA. 


RQ9.87 


If the CLF detects the end of the PICC deactivation sequence by the external contactless reader, the 

i n i — a in i i — \ i~w /~\ a r~i i- \ i- \ i — a /-\ ~i~ i \ / a ~i~ i — r~\ 

card RF gate shall send an EVTCARDDEACTIVATED 


RQ9.88 


In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate. 


RQ9.89 


When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gid- 


RQ9.90 


In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host 



NOTE: Development of test cases for RQ9.83, RQ9.89 is FFS. 

5.6.4.1 .2 Test case 1 : ISO/IEC 14443-3 Type A 

5.6.4.1.2.1 Test execution 

Run this test with the following parameters: 

• Full power mode. 

5.6.4.1.2.2 Initial conditions 

• A PIPEa is created and opened by the host with source G ro = '21' to the card RF gate of type A of HCUT. 

• Registries entries of card RF gate for RF technology type A shall be modified to execute the test. 

• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type A protocol is powered off. 



5.6.4.1.2.3 Test procedure 



Step 


Direction 


Description 


RQ 


1 


User HCUT 


The terminal is placed in PCD field. 




2 


PCD HCUT 


Transitions from POWER OFF to IDLE state. 




3 


HCUT^ HS 


Send EVT FIELD ON. 


RQ9.82 


4 


PCD -» HCUT 
HCUT PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type A (with anti-collision 
and selection). 


RQ9.84 


5 


PCD -» HCUT 


Send (RATS). 




6 


HCUT^ PCD 


Response (ATS). 




7 


PCD HCUT 
HCUT PCD 


PPS procedure. 




8 


HCUT HS 


Send EVT CARD ACTIVATED. 


RQ9.85 


9 


PCD -» HCUT 


Send C-APDU. 




10 


HCUT^ HS 


Send EVT SEND DATA contains the received C-APDU on PIPEa. 


RQ9.86 


11 


HS^ HCUT 


Send EVT SEND DATA contains the response on PIPEa. 




12 


HCUT PCD 


Send R-APDU. 




13 




If there is more data to exchange than repeat step 9 to 12. 




14 


User HCUT 


Run the deactivation sequence. 




15 


PCD HCUT 


Send DESELECT command. 




16 


HCUT^ HS 


Send EVT CARD DEACTIVATED. 


RQ9.87 


17 


User HCUT 


The terminal is removed from the PCD field. 




18 


HCUT^ HS 


Send EVT FIELD OFF. 


RQ9.88, 
RQ9.90 
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5.6.4.1 .3 Test case 2: ISO/IEC 14443-3 Type B 

5.6.4.1.3.1 Test execution 

Run this test with the following parameters: 

• Full power mode. 

5.6.4.1.3.2 Initial conditions 

• A PIPEa is created and opened by the host with source Gi D = '21' to the card RF gate of type A of HCUT. 

• Registries entries of card RF gate for RF technology type B shall be modified to execute the test. 



• The Proximity Coupling Device (PCD) supporting ISO/IEC 14443-3 [6] Type B protocol is powered off. 



Step 


Direction 


Description 


RQ 


1 


User HCUT 


The terminal is placed in PCD field. 




2 


PCD HCUT 


Transitions from POWER OFF to IDLE state. 




3 


HCUT HS 


Send EVT FIELD ON. 


RQ9.82 


4 


PCD HCUT 
HCUT^ PCD 


Perform initialization of RF ISO/IEC 14443-3 [6] Type B (with anti-collision 
and selection). 


RQ9.84 


5 


PCD HCUT 


Send (RATS). 




6 


HCUT^ PCD 


Response (ATS). 




7 


PCD HCUT 
HCUT^ PCD 


PPS procedure. 




i 8 


HCUT -> HS 


Send EVT CARD ACTIVATED. 


RQ9.85 


9 


PCD HCUT 


Send C-APDU. 




10 


HCUT HS 


Send EVT SEND DATA contains the received C-APDU on PIPEa. 


RQ9.86 


11 


HS HCUT 


Send EVT SEND DATA contains the response on PIPEa. 




12 


HCUT^ PCD 


Send R-APDU. 




13 




If there is more data to exchange than repeat step 9 to 1 2. 




14 


User HCUT 


Run the deactivation sequence. 




15 


PCD HCUT 


Send DESELECT command. 




16 


HCUT^ HS 


Send E VT_C A R D_D E ACTI VATE D . 


RQ9.87 


17 


User HCUT 


The terminal is removed from the PCD field. 




18 


HCUT HS 


Send EVT FIELD OFF. 


RQ9.88, 
RQ9.90 



5.6.4.2 Non ISO/IEC 1 4443-4 type A 
5.6.4.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.2. 



RQ9.91 


In full power mode, and if SWP is not in DEACTIVATEDstate, when the CLF detects a RF field, the card 
RF gate shall send the event EVT FIELD ON to the card application gate. 


RQ9.92 


When there are multiple open card RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gid- 


RQ9.93 


When the CLF detects a RF field, and after sending EVT FIELD ON (if sent), the CLF shall start the 
initialization and anti-collision process as defined in ISO/IEC 14443-3 [6] using the parameters from the 
card RF gate registry for the RF technology type A. 


RQ9.94 


Any other communications are done using the CLT mode as defined in TS 1 02 61 3 [2]. 


RQ9.95 


In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT_FIELD_OFF to the card application gate.. 


RQ9.96 


When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gid. 


RQ9.97 


In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT FIELD OFF to the card application gate or power down the host. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.6.4.3 



Type B' RF technology 



5.6.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.3. 

NOTE: Defining conformance requirements is out of scope of the present document. 



5.6.4.4 



Type F RF technology 



5.6.4.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.4. 



RQ9.98 


In full power mode, and if SWP is not in DEACTIVATED state, when the CLF detects a RF field, the card 
RF gate shall send the event EVT FIELD ON to the card application gate. 


RQ9.99 


When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_ON to the open card 
application gate with the lowest Gid- 


RQ9.100 


In case SWP as defined in TS 102 613 [2] is used as a data link layer, when the CLF detects a RF field, 
and after sending EVT_FIELD_ON (if sent), the CLF shall start the initialization and anti-collision process 
performed using CLT as defined in TS 102 613 [2] for the RF technology ISO/IEC 18092 [4] 
212 kbps/424 kbps passive mode type F. 


RQ9.1024 


The card RF gate shall forward the ISO/IEC 18092 [4] 212 kbps/424 kbps frames from the external 
reader to the card application gate using the EVT SEND DATA with the structure specified in TS 102 
622 [1]. 


RQ9.103 


The host sending a response shall encapsulate the ISO/IEC 18092 [4] 212 kbps/424 kbps frames in an 
EVT SEND DATA event and shall send it to the card RF gate. 


RQ9.104 


In full power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall send EVT FIELD OFF to the card application gate.. 


RQ9.105 


When there are multiple open cards RF gates the CLF shall send the EVT_FIELD_OFF to the card 
application gate used during the transaction or to the open card application gate with the lowest Gid. 


RQ9.106 


In low power mode, when the CLF detects at any time during the sequence that the RF field is off, the 
card RF gate shall either send EVT_FIELD_OFF to the card application gate or power down the host 


RQ9.107 


ISO/IEC 18092 [4] 212 kbps/424 kbps frames, except initialization command and response (command 
code '00' and '01'), shall be exchanged using the appropriate gate depending on the command code of 
the frame as described in TS 102 622 [1]. 


RQ9.108 


The command codes reserved for the NFCIP-1 protocol shall not be forwarded. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.6.4.5 Update RF technology settings 
5.6.4.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.5. 
There are no conformance requirements for the terminal for the referenced clause. 

5.6.4.6 Identity check 

5.6.4.6.1 Conformance requirements 

Reference: TS 102 622 [1], clause 9.4.6. 



RQ9.110 



If the lower identity check fails, the host controller shall not respond to the external contactless reader 
with any parameter from the card emulation registries related to the UICC host. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.7 Contactless reader 

5.7.1 Overview 

5.7.1.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.1. 



RQ10.1 


The host controller has one reader RF gate for each RF technology it supports. 


RQ10.2 


The CLF shall handle the RF layers of the communications as defined in ISO/IEC 14443-2 [5]. 


RQ10.3 


The anti-collision and activation as defined in ISO/IEC 14443-3 [6] shall be handled by the CLF 
under the control of the host. 


RQ10.4 


The RF protocol as defined in ISO/IEC 14443-4 [7] shall be handled by the CLF. 


RQ10.5 


The reader RF gate and reader application gate shall exchange APDUs defined in ISO/IEC 7816-4 
[8] over their pipe. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.2 Reader RF gates 

5.7.2.1 Overview 

Reference: TS 102 622 [1], clause 10.2.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.2.2 Command 
5.7.2.2.1 WR_XCHG_DATA 
5.7.2.2.1.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.2.2.1. 



RQ10.6 


If b5 of the CTR field of WR_XCHG_DATA is set to zero, application level time-out is deactivated. 


RQ10.7 


If b5 of the CTR field of WR_XCHG_DATA is set to one, then b4 to b1 is a time-out value which shall 
use to calculate the application level time-out with the formula specified in TS 102 622 [1]. 


RQ10.8 


When command WR_XCHG_DATA is successful, the host controller shall respond with ANY_OK 
with parameter which contains the data received and the RF error indicator. 


RQ10.9 


When command WR_XCHG_DATA is successful, the RF error indicator shall be '00' if no error. 


RQ10.10 


When command WR_XCHG_DATA is successful, the RF error indicator shall be '01' if error. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.2.3 Registries 

5.7.2.3.1 Type A reader RF gate 

5.7.2.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.1. 
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KU1 U.l 1 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 




The registry is not persistent. 


nUl U.l O 


The values are updated after each target activation. 


nUl U.l 4 


i ne L/Lr snail set a aeiauit vaiue ror uiu ritu ot utsuuuuuu . 


□ AH A -j r 

nUl U.l 


The CLF shall apply the access condition of RO for UID. 


QAH AHA 

nUl U.l O 
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nUl U.l / 


The CLF shall apply the access condition of RO for ATQA. 


nUl U.l o 


i ne OLr snan usg a oeTauit vaiue Tor ArrLiOA i iuin_ua i a ot an Gmpty array. 
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nU I u. i y 
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□ AH A on 
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i ne L/Lr snan use a aerauiT vaiue Tor oaks, ot uu . 


RQ10.21 


The CLF shall apply the access condition of RO for SAK. 




TU rt C ok»oll i i r\ o rlnf^i lit will frw OA/I CLf^T ^f 'CC 

i ne L/Lr snan use a aerauit vaiue ror rvvi, orLi i ot tt 


RQ10.23 


The CLF shall apply the access condition of RO for FWI, SFGT. 


RQ10.24 


The CLF shall set a default value for DATARATE MAX of '00'. 


RQ10.25 


The CLF shall apply to the access condition of RW to DATARATE MAX. 


RQ10.26 


The CLF shall accept valid values of DATARATE MAX as defined in TS 102 622 [1]. 


RQ10.27 


The maximum supported divisor used over the RF interface shall be the minimum of the value as 
indicated in the registry and the maximum divisor implemented in the CLF. 



NOTE: Development of test cases for above listed RQs is FFS. 



5.7.2.3.2 



Type B reader RF gate 



5.7.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.3.2. 



RQ10.28 


Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 


RQ10.29 


The registry is not persistent. 


RQ10.30 


The values are updated after each target activation. 


RQ10.31 


The CLF shall use a default value for PUPI of 'N0=0'. 


RQ10.32 


The CLF shall apply the access condition of RO for PUPI. 


RQ10.33 


The CLF shall use a default value for APPLICATION DATA of 'N1=0'. 


RQ10.34 


The CLF shall apply the access condition of RO for APPLICATION DATA. 


RQ10.35 


The CLF shall set a default value for AFI of '00'. 


RQ10.36 


The CLF shall apply the access condition of RW to AFI. 


RQ10.37 


The CLF shall use a default value for HIGHERLAYERRESPONSE of 'N2=0'. 


RQ10.38 


The CLF shall apply the access condition of RO to HIGHER LAYER RESPONSE. 


RQ10.39 


The CLF shall set a default value for H I G H E R LA YE R_D ATA of 'N3=0'. 


RQ10.40 


The CLF shall apply the access condition of RW to HIGHER LAYER DATA. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.2.4 Events and subclauses 



5.7.2.4.1 



Events 



5.7.2.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4. 



RQ10.41 



The reader RF gates shall support the EVT_READER_REQUESTED and EVT_END_OPERATION 
events. 



NOTE: Development of test cases for above listed RQs is FFS. 
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5.7.2.4.2 EVTREADERREQUESTED 
5.7.2.4.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.2.4.1. 



RQ10.42 


On receiving the EVT READER REQUESTED event, the CLF shall activate the RF polling (turn on the 
RF carrier) 


RQ10.43 


The CLF shall accept EVT READER REQUESTED event on any open pipe of any reader RF gate. 



NOTE: Development of test cases for above listed RQs is FFS. 
5.7.2.4.3 EVTENDOPERATION 

5.7.2.4.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.2.4.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.2.5 Responses 

5.7.2.5.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.2.5. 



RQ1044 


If command WR_XCHG_DATA is successful, response shall be ANY OK. 


RQ10.45 


If command WR_XCHG_DATA is rejected and /or not completed, response shall be ANY E OK. 


RQ1046 


If Application level time-out occurred, the response shall be ANY_E_TIMEOUT. 


RQ10.47 


If Target has returned an RF error the response shall be 'WR_RF_ERROR. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.3 Reader application gates 

5.7.3.1 Overview 

Reference: TS 102 622 [1], clause 10.3.1. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.2 Command 

5.7.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.2. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.3 Registry 

5.7.3.3.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.3. 
There are no conformance requirements for the terminal for the referenced clause. 
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5.7.3.4 Events and subclauses 

5.7.3.4.1 Events 

5.7.3.4.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 10.3.4. 
There are no conformance requirements for the terminal for the referenced clause. 

5.7.3.4.2 EVTTARGETDISCOVERED 
5.7.3.4.2.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.3.4.1. 



RQ10.48 


The existence of an RF target in the field of the activated RF technology shall be signalled to the 
reader application gate by EVT TARGET DISCOVERED event. 


RQ10.49 


If there is a single target in the reader field and the activation of the target is completed then the 
value of STATUS parameter of EVT TARGET DISCOVERED event shall be equal to '00'. 


RQ10.50 


If there are several targets in the field irrespective of the RF technology then the value of STATUS 
parameter of EVT TARGET DISCOVERED event shall be equal to '03'. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.7.4 Procedures 

5.7.4.1 Use of contactless reader application 
5.7.4.1.1 Conformance requirements 



Reference: TS 102 622 [1], clause 10.4.1. 



RQ10.51 


On receiving the EVT READER REQUESTED event, the CLF shall enable the RF polling. 


RQ10.52 


Once RF polling is enabled, the CLF shall start the detecting of a target according to all reader RF 
gates of the host that have an open pipe 


RQ10.53 


When a target has been detected and activated, the CLF shall notify the host via the event 
EVTTARGETDISCOVERD, 


RQ10.54 


If the several targets in the field then the procedure shall stop. 


RQ10.55 


When the CLF receives a response from the target to a forwarded C-APDU, the reader RF gate shall 
reply in sending back an R-APDU to the reader application gate. 


RQ10.56 


If an application level time-out occurs before the CLF receives a response from the target, the CLF 
shall respond to the UICC with ANY_E_TIMEOUT 


RQ10.57 


Once the CLF responds with ANY E TIMEOUT, it shall discard data received from the target 
thereafter. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8 Connectivity 
5.8.1 Overview 

Reference: TS 102 622 [1], clause 11.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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5.8.2 Connectivity gate and subclauses 

5.8.2.1 Connectivity gate 

Reference: TS 102 622 [1], clause 11.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.2 Commands 

5.8.2.2.1 PRO_HOST_REQUEST 

5.8.2.2.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.1.1. 



RQ11.1 



When the Terminal Host receives an PRO_HOST_REQUEST, it shall attempt to activate every host in 
the list of host identifiers during the Activation Duration. 



RQ11.2 



If every requested host has successfully been activated, the Terminal Host shall send an ANY OK 
response with no parameters. 



RQ11.3 



If no requested host has been successfully activated, the Terminal Host shall send a response which is 
not ANY OK. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.3 Events and subclauses 

5.8.2.3.1 Events 

Reference: TS 102 622 [1], clause 11.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.2 EVT_CONNECTIVITY 

5.8.2.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.1. 



RQ11.4 



When the Terminal Host receives an EVT_CONNECTIVITY, it shall send a "HCI connectivity event" as 
defined in TS 102 223 [3], 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.3.3 Void 

Reference: TS 102 622 [1], clause 11.2.2.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.2.3.4 EVTOPERATIONENDED 

5.8.2.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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5.8.2.3.5 EVTTRANSACTION 

5.8.2.3.5.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.2.4. 



RQ11.5 



When the Terminal Host receives an EVT_TRANSACTION, it shall attempt to launch an application 
associated to an NFC application in a UICC host identified by the AID. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.2.4 Registry 

5.8.2.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.2.3. 



RQ11.6 



Registry parameters which are in the range reserved for usage by TS 102 622 [1] but which are not 
defined in TS 102 622 [1] shall not be present in the registry. 



NOTE: Development of test cases for above listed RQs is FFS. 

5.8.3 Connectivity application gate and subclauses 

5.8.3.1 Connectivity application gate 
5.8.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.2 Commands 

5.8.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.3.3 Events and subclauses 
5.8.3.3.1 Events 

5.8.3.3.1.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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5.8.3.3.2 EVTSTANDBY 

5.8.3.3.2.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.2.1. 
|RQ1 1 .7 | When the terminal host send EVT_STANDBY, it shall not contain parameters. | 

NOTE: Development of test cases for above listed RQs is FFS. 

5.8.3.4 Registry 

5.8.3.4.1 Conformance requirements 

Reference: TS 102 622 [1], clause 11.3.3. 
There are no conformance requirements for the Terminal Host for the referenced clause. 

5.8.4 Procedures 

5.8.4.1 Use of connectivity gate 

Reference: TS 102 622 [1], clause 11.4.1. 
There are no conformance requirements for the Terminal Host for the referenced clause. 
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